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ABSTRACT 


The purpose of this study was to determine potential improvements in Navy 
Medicine’s current Certification and Accreditation (C&A) process. The study examined 
whether Navy Medicine’s C&A policies are in alignment with DoD, Navy and Federal 
Government requirements and whether the use of automated C&A tools could 
significantly improve Navy Medicine’s current C&A security posture. 

The primary research reviewed C&A policy and included a comparative analysis 
of two cutting edge automated C&A tools namely, Xacta and eMASS. The findings of 
the analysis revealed that the use of automated C&A tools could significantly enhance 
Navy Medicine’s C&A process and assist Navy Medicine’s information assurance 
personnel who are responsible for the execution of the Navy Medicine C&A process and 
approval of Navy Medicine information systems. This study also provided valuable 
insight in verifying the evidence on how information assurance (lA) controls are 
addressed within the automated C&A tools regardless of the C&A process. The results of 
the analysis ultimately led to the development of key recommendations that can assist 
Navy Medicine in selecting the appropriate automated C&A tool for its C&A process. 
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I. 


INTRODUCTION 


A. BACKGROUND 

The U. S. government has gone from a manual method of doing business to a 
state of information technology (IT) reliance within a relatively few years. Today, the 
government relies on IT to such a degree that if abruptly taken away, enterprises would 
crumble. IT comprises much of the critical information infrastructure within the United 
States. 

As technology advances, information systems become more and more complex to 
keep up with the growing ideas for automation and business benefit of increased 
productivity and service. The complexity of systems is a driving force for assessing the 
security using both technical and non-technical approaches. Information security must 
ensure confidentiality, integrity, and availability to protect the privacy of the public, and 
at the same time ensure availability of the services that the users of the systems require. 
It' is a fundamental management responsibility to ensure that the appropriate security 
controls are in place. Creating a living program to identify and mitigate risks will help 
information system owners certify that a system is secure from theft, modification, and 
disruption or destruction of service. Most government agencies that are not part of DOD 
do not have classified information that pose a national threat if compromised. However, 
they do have sensitive information about the public and their own business processes that 
need to be protected. It not only makes sense to protect this information and certify the 
security for information systems, it is the law. 

On December 17, 2002, President Bush signed the E-Govemment Act of 2002, 
which included the Federal Information Security Management Act (FISMA). That 
signing made the requirements identified in the Government Information Security 
Reform Act of 2000 permanent. In effect, that permanently codified 0MB Circular A- 
130 into law and made it a requirement for each government system be certified and 
accredited prior to implementation and at least every three years after that. 
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A study of lessons learned from the first year under the Federal Information 
Security Management Act (FISMA) seems to pinpoint certification and accreditation 
(C&A) as the most important aspect of compliance. 

The certification and accreditation process is a comprehensive analysis of the 
technical and non technical components of an IT system that needs to be completed 
before a system is moved into production. The analysis needs to be completed in an 
operational environment to determine that the controls and system artifacts have been 
incorporated in compliance with Federal, Departmental, and other pertinent regulations or 
laws. Some examples of non-technical controls to be assessed are: system security 
documentation, physical security, personnel security, and administrative procedures. 
Some examples of the technology that provide security are encryption devices/software, 
firewalls, access control, and audit tools. This is only a partial list of items to think about. 
The system being certified needs a list that matches its own security configuration and 
needs. Certification is a structured process that verifies techniques and procedures during 
the system's life cycle. It ensures that controls are implemented correctly and are effective 
to protect system confidentiality, integrity, and availability (CIA). Accreditation is the 
formal declaration by a designated approving authority that an information system is 
acceptable to perform in a prescribed security mode using a formal set of safeguards 
(Committee on National Security Systems CNSSI-4009, 2003). According to the 
Department of Defense, the certification and accreditation process can be broken down 
into four main phases: Definition, Verification, Validation and Post Accreditation. 

This Definition phase establishes a comprehension of the Information System (IS) 

business case or mission, environment, and architecture to identify the security 

requirements and certification level of effort to accomplish accreditation. The goal is to 

conform on the system mission, operating environment, security requirements, C&A 

boundary, schedule, level of effort, and resources required. The creation of the System 

Security Authorization Agreement (SSAA), which is the binding agreement on the 

required level of security before system development begins, is included in the definition 

phase. The Verification phase supports the system’s compliance with the information 

security requirements and constraints identified and documented in the SSAA. The 

intention is to certify that the IS or components satisfy the security requirements. The 
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Validation phase reinforces compliance by an independent validation of the fully 
integrated version of the system to the operational requirements and security policy stated 
in the SSAA. The intent is to provide documented evidence to assist the DAA in making 
an informed qualified decision to permit approval for full system operation either by 
system accreditation or interim authority to operate (lATO). The Post Accreditation 
phase consists of activities that are used to monitor system management and operation 
within a level of acceptable residual risk. The system security management, change 
management, and annual compliance validation reviews are administered during this 
phase. 

The C&A process can be tedious, costly and resource demanding. Ideally, the 
C&A process encompasses the entire life cycle of the system. It is a continuing, dynamic 
process. According to the Office of Management and Budget’s (0MB) March 2004 
report to the Congress, the authorized funding for IT security has increased from $2.7 
billion in FY 2002 to $4.2 billion in FY 2003. However, a total of eighteen (18) agencies 
identified funding as a challenge to performing their certifications and accreditations. For 
example, the Department of Commerce (DOC) noted that their certification and 
accreditation was an expensive process and that in order to develop and implement its 
program, it had to reprogram and reprioritize internal funds and absorb costs in existing 
funding levels. In another case, the Department of Health and Human Services (DHHS) 
stated that because of limited funding, higher emphasis is placed on using funds to certify 
and accredit new systems as opposed to existing systems. The Department of Energy 
(DOE) also noted that funding was a challenge because security costs were not integrated 
into the overall life-cycle costs for all of its systems. Despite these and other concerns 
related to security cost funding, most agencies did not know how much they spent on 
certification and accreditation. For example, only 11 agencies could identify their actual 
or estimated costs for fiscal year 2003, which totaled $75.5 million for these agencies 
(GAO report on Information Security, 2004). 

Nineteen (19) agencies surveyed also reported that they had encountered staffing 

challenges for their certification and accreditation activities that essentially consisted of 

the need for full-time staff with the appropriate backgrounds, specialized skills, and 

security clearances. In addition, thirteen (13) agencies reported challenges in providing 
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training to staff or officials responsible for certifying or accrediting agency systems 
(GAO report on Information Security, 2004). 

As identified in the certification process, one of the most difficult, time 
consuming, and expensive task is to create and conduct the Security Test and Evaluation 
(ST&E) plan that is part of the Validation phase. The commitment to conduct and support 
ST&E requires considerable amount of manpower and financial resources from the 
agencies. Developing this plan is very challenging especially if it has to be done for the 
hundreds of systems owned by most Federal Agencies and military commands. One 
enormous task for creating the ST&E plan is to determine what non-Agency regulations 
and guides need to be included for testing, and then what types of tests should be scripted 
from them. Another major concern in the C&A process is defining system boundaries for 
numerous systems that need C&A. The demand on manpower resources to collect actual 
system environment information can be a daunting task. The C&A of high assurance 
systems would require more resources in the development of complex formal models and 
hiring of specialized skilled labor. An additional problem exists when storing and 
maintaining the System Security Authorization Agreement (SSAA) for so many systems, 
especially when the components in the SSAAs may be in different formats. The SSAA 
needs to be stored for future use — According to Federal regulation; certification needs to 
be completed at least every three years for every system identified on an Agency's 
inventory. 

In Special Publication 800-37, the National Institute of Standards and Technology 
(NIST) confirms that the cost of conducting certifications and accreditations on large 
numbers of information systems with varying degrees of complexity is a critical issue 
confronting existing agencies. NIST recommends as part of their solution is the 
promotion of reuse and sharing of security control development, implementation, and 
assessment-related information in the agency's agency wide information security program 
(GAO report on Information Security, 2004). 

Another possible solution is to use an automated C&A tool that aheady has test 
scripts for Federal regulations and guidance together with having industry best practices 
already built in. This would mean using an automated C&A tool that can create a 
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repository of SSAAs, in a standard format for future use. Using an automated C&A tool 
that provides a standard, repeatable certification and accreditation process will greatly 
improve the current C&A process. 


B. PURPOSE 

The purpose of this thesis is to determine improvements in Navy Medicine’s 
current Certification and Accreditation (C&A) process. This is done by determining 
whether the current Navy Medicine C&A policies and resultant efforts properly address 
the current C&A requirements confronting Navy Medicine networking professionals. A 
comparative evaluation of two automated C&A software solutions, namely Xacta and the 
Enterprise Mission Assurance Support System (eMASS), will be done. It will determine 
if the C&A software solutions can improve the implementation of the C&A process in 
Navy Medicine. 

C. RESEARCH QUESTIONS 

The following questions were used to guide the research and development of this 

thesis: 

1. Are existing Navy Medicine Certification and Accreditation (C&A) 
policies in alignment with current Department of Defense (DoD), Navy 
Policy and federal government requirements? 

2. Would the use of automated (C&A) software tools assist the Navy 
Medicine (C&A) process in obtaining system accreditation? 

3. Would the use of automated (C&A) tools be a cost-effective means to 
address Navy Medicine C&A lA threats and vulnerabilities? 

4. Would a consolidated and centrally-managed knowledgebase of (C&A) 

policies improve Navy Medicine current security posture? 
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D. SCOPE OF RESEARCH 

This thesis will cover the vital aspects of Navy Medicine’s current C&A policies. 
It will examine if Navy Medicine’s current C&A policies and implementation efforts 
properly address current federal C&A requirements that are confronting Navy medicine 
IT professionals. It will also evaluate several C&A software solutions and examine how 
these solutions can improve the implementation of Navy medicine’s current C&A 
policies within its claimancy. 

E. METHODOLOGY 

The methodology used for this research consists of the following steps: 

1. Conducting a literature search of books, joumal/magazine articles, 
CDROM systems, and other library information resources for the Xacta 
and eMASS C&A software solutions using key word queries. 

2. Conducting a thorough review of Navy Medicine’s current certification 
and accreditation process (DITSCAP) and resultant efforts in properly 
addressing federal and DoD requirements confronting Navy Medicine IT 
professionals. 

3. Determining the information assurance (IA) controls satisfying the 
confidentiality, integrity and availability assurance level requirements for 
health care data based on the DoDI 8500.2, Information Assurance (lA) 
Implementation Policy. 

4. Mapping the lA controls of DoDI 8500.2 to the DITSCAP SSAA and 
evaluating unmapped sections of the DITSCAP SSAA. 

5. Exploring and contrasting the capabilities of two C&A software solutions 
Xacta and eMASS. 

6. Determining how each software solution provides Navy Medicine IT 
management with the necessary tools, information and benefits to assist 
them in accomplishing a sound, informed, and timely certification and 
accreditation of their networks. 


6 



7. Interviewing other healthcare organizations and DoD agencies that may 
add value to this thesis. 

8. Discussing the effect of having a consolidated and centrally managed 
knowledgebase of certification and accreditation policies in increasing 
Navy Medicine’s current security posture. 

The information that was collected for this thesis was obtained using the 
following methods: 

1. Public Laws 

• Privacy Act of 1974, P.L. 93-579,5 U.S.C. 552a (1974) 

• Computer Security Act of 1987 P.L. 100-235 (1988) 

• The Clinger-Cohen Act of 1996 

• Management of Federal Information Resources (0MB Circular A-130, 
Appendix III, “Security of Federal Automated Information Systems”, 

1996 

• Health Insurance Portability and Accountability Act of 1996, Public Law 
104-191 (HIPAA) 

• Presidential Decision Directive-63 (PDD-63), 1998 

• Gramm-Leach-Bliley Act of 1999, Public Law 106-102 (GLBA) 

• Sarbanes-Oxley Act of 2002, Public Law 107-204 (SARBOX) 

• The E-Govemment Act of 2002 (Public Law 107-347) 

• Federal Information Security Management Act of 2002 

• NIST Special Pub 800-37 - Guidelines for the Security Certification and 
Accreditation of Federal Information Technology System 

• NCSC-TG-031 - Certification and Accreditation Process Handbook for 
Certifiers 

• NCSC-TG-029 vl - Introduction to Certification and Accreditation 

• NSTISSI No. 1000 - National Information Assurance Certification and 
Accreditation Process (NIACAP) 

2. DoD Policies and Guidelines 

• DoD 5200.40 - DoD Information Technology Security Certification and 
Accreditation Process (DITSCAP) 

• DoD 8510.1 -M - DoD Information Technology Security Certification and 
Accreditation Process (DITSCAP) Manual 

• DoD Directive 8500.1 - Information Assurance (lA) 

• DoD Directive 8500.2 - Information Assurance (lA) Implementation 

3. Navy Medicine Policies and Guidelines 

• Military Health System (MHS) Information Assurance (lA) Policy / 
Guidance Manual 
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• Bureau of Medicine and Surgery (BUMED) Information Assurance 
Information Systems Security Policy Manual. 

F. DISCLAIMER AND LIMITATIONS 

The information that was used to assemble and analyze research findings is 
applied to satisfy the academic reporting requisites needed for the completion of a Master 
of Science Degree in Information Systems Technology from the Naval Postgraduate 
School. Interviews will be limited to the key Information Assurance Managers/Officers 
(lAM/IAO), account managers and staff of the Navy Medicine Enterprise Security 
Department - Technology and Information Directorate, IA and C&A Branch - Space 
Warfare Systems Command (SPAWAR) San Diego and Charleston, Telos Corporation 
and Information Assurance Technology Analysis Center. Additionally, research 
information or any other organizational data that was used within this research paper will 
be held in strict confidence and used solely for the indicated purpose. 

The length of the academic term further limits the scope of the study and the 
efforts of this research may or may not accurately represent the other components of the 
United States Navy in regards to DAA, PM, UR, ISSM, ISSO and lAM/IAO or any other 
DoD representatives that fit the above mentioned titles or position. 
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II. BACKGROUND 


A. INTRODUCTION 

It is the main responsibility of the entire Federal Govern m ent to ensure the 
protection of all its information from unauthorized disclosure. This process of 
safeguarding all information in the Federal Government is called certification and 
accreditation. The certification authorities or certification agents enforce the certification 
and accreditation process. 

A Certification Authority (Certifier) is the technical expert in the certification and 
accreditation process. The certifier is involved in the program’s life cycle activities. It is 
the certifier’s job to 1) confirm that the system or component determines and complies 
with the proper set of security requirements, 2) document and evaluate the residual risk 
and 3) submit a recommendation to the approving authority whether to allow the system 
or component to function thereby accepting the associated risk. 

A Certification Agent is a Naval term describing a person who assists the 
certification authority. The certification agent’s responsibilities are 1) to provide 
assistance in the development of the security engineering process 2) to assess and/or 
gather factual information that would be presented to the approving authority. This 
information will assist the approving authority to make a sound judgment whether to 
allow or disallow the continued operation of the system or component. 

The Certification Authority and Certification Agent follow numerous Federal and 
DoD information assurance policies in enforcing the certification and accreditation 
process. The next section will briefly describe the information assurance requirements 
involved in the development of information security policy in the Federal Government, 
DoD and Navy Medicine. 

B. INFORMATION ASSURANCE POLICY REQUIREMENTS 

This section describes a few sources of information assurance requirements for 
Government automated information systems and components that DoD and Navy 
Medicine must satisfy. Governing Federal information assurance instructions and 
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directives define basic information assurance requirements. These requirements serve as 
a basis for establishing more defined administrative and technical security specifications, 
design and operational requirements. 

1. Federal Government IT Security Requirements 

a. Privacy Act of1974, P.L. 93-579, 5 U.S.C. 552a (1974) 

The Privacy Act of 1974 mandate all governmental agencies to protect all 
personal data generated and processed by automated information systems. This Privacy 
Act also directs the federal agencies to permit personnel to know what information is 
being managed. Updating inaccurate personal information is permitted by this Privacy 
Act. The Act focuses on the aspects of physical security policies, information 
management procedures, and desktop network oversight for systems that handle Privacy 
Act related data. 

b. Computer Security Act of1987 P.L. 100-235 (1988) 

The Computer Security Act of 1987 went into effect on January of 1988. 
The Act requires all computer systems owned by the U.S. federal government that handle 
sensitive information to be managed by a security plan. The security plan must be 
tailored to address the specific management and usage of the system. The Act requires 
regular computer security awareness training for all federal employees, civilian 
contractors and other personnel directly involved in government sponsored programs. 

c. The Clinger-Cohen Act of1996 P.L. 104-106 

The Clinger-Cohen Act is the combination of the Information Technology 
Management Reform Act (ITMRA) and the Federal Acquisition Reform Act (FAR). This 
Act was the result of the Federal Government’s increased reliance on Information 
Technology and the resulting increased attention and oversight on its acquisition, 
management and use. The Act requires major federal agencies to establish the position of 
Chief Information Officer (CIO) who has the clear authority, responsibility and 
accountability for the Agency’s information resources management activities and 
providing for greater coordination among the Agency’s information. The Act also 
clarifies the responsibilities of the DoD CIO with those of the Military CIOs. The 
Military CIOs act as advisors to the DoD CIO, who in turn, advises the Secretary of 
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Defense in promoting improvements to the DoD work processes and supporting 
information resources. 

The Act delegates to the DoD CIO all the responsibilities given to the 
head of the federal agency. The agency head together with the CIO ensures that the 
information security policies, procedures and practices of the agency are complete and 
current. 

d. Management of Federal Information Resources (0MB Circular 
No. A-130, Appendix HI, "Security of Federal Automated 
Information Systems", 1996) 

The 0MB Circular No. A-130 Appendix III, which was revised in 
February 1996, establishes a minimum set of controls to be included in Federal 
automated information security programs. It assigns Federal agency responsibilities for 
the security of automated information. It also links agency automated information 
security programs and agency management control systems established in accordance 
with 0MB Circular No. A-123. The Appendix revises procedures formerly contained in 
Appendix III to 0MB Circular No. A-130 (50 FR 52730; December 24, 1985), and 
incorporates requirements of the Computer Security Act of 1987 (P.L. 100-235) and 
responsibilities assigned in applicable national security directives. 

The 0MB Circular No. A-130 focuses more on management controls, 
individual responsibility and accountability together with periodic awareness training, 
than focusing on technical and engineering controls. Federal agencies must ensure that 
risk-based rules of behavior and function are well established. All employees are to be 
provided with documented training and that the rules are enforced. It specifically requires 
agencies to manage and execute a program to make certain that all agency data collected, 
processed, transmitted, stored, or disseminated in general support systems and major 
applications are adequately secured. A formal risk analysis is no longer required in 
Appendix III. Instead, general risk assessments are addressed by risk-based management. 
The applications, vulnerabilities, threats, and safeguard effectiveness are considered 
major risk-based management factors. Ultimately, 0MB, NIST, and NSA play a major 
role in assisting and providing guidance to the major federal agencies in order to improve 
their computer security posture. This appendix also requires a system security Plan (SSP) 
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and the appointment of a person responsible for the security of the system who has the 
authority to assume and accept the risk which is the Designated Approving Authority 
(DAA). 

e. Health Insurance Portability and Accountability Act of 1996 
(HIPAA) PL. 104-191 

The HIPAA Security and Privacy Rule of 1996 was mandated by 
Congress to address the development of a national privacy law, security standards, and 
electronic transactions standards and provides penalties for standards violations and 
wrongful disclosures of health information. The Final HIPAA Security Rule was passed 
down by the Department of Health and Human Services with an effective date of 21 
April 2003. Most HIPAA covered entities will have two full years until 21 April 2005 to 
comply with the standards. The HIPAA Security Rule particularly addresses the concern 
of the protection of electronic protected health information (EPHI). The confidentiality, 
integrity, and availability of electronic protected health information are the main goal of 
the HIPAA Security Rule. The HIPAA Security Rule further defines the steps and 
procedures for the proper handling and use of EPHI. As part of DoD and the Federal 
Government, compliance to the Final HIPAA Security Rule is required of all Navy 
Medicine facilities and health care providers. The establishment and enforcement of a set 
of security standards for securing certain patient health care information is the 
responsibility of all health care providers in the civilian and military treatment facilities. 
The definition of a health care provider is any provider of medical or other health 
services, or supplies, which handles or processes any health information in electronic 
form in conjunction with a contract or transaction for which a standard has been applied. 

This final rule adopts standards for the security of electronic protected 
health information to be implemented by health plans, health care clearinghouses, and 
certain health care providers. The use of the security standards is aimed to improve the 
Medicare and Medicaid programs, and other Federal health programs and private health 
programs, and the effectiveness and efficiency of the health care industry in general by 
establishing a level of protection for certain electronic health information. This Final 
HIPAA Security Rule implements some of the requirements of the Administrative 
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Simplification subtitle of the Health Insurance Portability and Accountability Act of 1996 
(HIPAA). 

f. Presidential Decision Directive — 63, (PDD-63), 1998 

This Presidential Decision Directive focused on a national effort to assure 
the security of the country’s critical infrastructures. The PDD-63 defines critical 
infrastructure as the physical and cyber-based systems essential to the minimum 
operations of the economy and the federal government. The critical infrastructures 
include, but not limited to, transportation, energy, finance, banking telecommunications 
and essential government services. 

PDD-63 complements and expands other laws and regulations that address 
the security of our nations key cyber systems. PDD-63 requires an independent review of 
the security plans for protecting nation’s critical systems. It requires the identification of 
the minimum essential infrastructure (MEI) that is critical to the operation of the 
economy and the federal government, including infrastructure interdependencies and the 
assessment of the MEI vulnerabilities across the major federal agencies. The PDD-63 
claims that focusing on these vulnerabilities require evolutionary and flexible solutions 
that will cater to different sectors of society. The dynamic nature of the threats to the 
critical infrastructures require frequent assessments of their reliability and vulnerability. 
The protective measures and corrective responses must be robust, flexible and adjustable 
to the constantly changing threats. 

g. The E-Government Act of2002 P.L. 107-347 

The E-Govemment Act of 2002 focuses on the critical relevance of 
information security and information assurance in E-Govemment. E-Govemment is 
defined as the use of information technology and the internet, together with the 
operational processes and people needed to implement these technologies, to deliver 
services and programs to constituents, including citizens, businesses and other 
government agencies. E-Govemment is aimed to improve the effectiveness, efficiency 
and quality of government services 

The Federal Information Security Act of 2002 (FISMA), which is title III 
of the E-Government Act, has assigned the National Institute of Standards and 

Technology (NIST) the responsibility for the standards and guidelines. Federal agencies 
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will use the development of the NIST standards to classify information and information 
systems that they maintain. This is based on the intent of providing appropriate levels of 
information assurance according to a range of corresponding risk levels in order to 
recommend the suitable types of information and information systems that should be 
included in each category 

h. Federal Information Security Management Act of2002 (FISMA) 

The FISMA of 2002 which was passed as title X of The Homeland 
Security Act and title III of the E- Govern m ent Act of 2002, mandates an increase of 
security for digital information and information systems in all federal offices. Under the 
supervision of The Department of Homeland Security, CIOs in every federal division 
must establish new stricter security measures replacing those in place under the old 
Govern m ent Information Security Reform Act of 2000 (GSRA). FISMA grants more 
responsibility and authority to NIST to develop and maintain standards for mandatory 
minimum information security and information assurance controls. 

The head of the federal agencies and their respective CIOs are directed by 
FISMA to establish an information security program that would be managed by trained 
agency personnel who are responsible for the enforcement of training. The full 
integration of information security and information assurance into the current and future 
business practices is one of the main goals of FISMA. 

The Designated Approving Authority (DAA), a senior management 
agency official, is required by FISMA to be responsible and accountable in authorizing 
each information system(s) in his agency for full operation using a formal certification 
and accreditation (C&A) process on the agency’s system. All federal information systems 
are required to be certified using the certification and accreditation process. The proper 
implementation and operation of appropriate security controls in the system is the main 
purpose of the C&A process. FISMA also requires the regular certification and 
accreditation of continuously operating agency information systems. 

The responsibility of providing information security safeguards on the 
scope and degree of damage as a consequence resulting from the unofficial access, 
handling, disclosure, disruption, alteration or destruction of data or information systems 
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belong to agency heads and their CIOs. It is required under FISMA that information 
security policies, practices and procedures are periodically tested and evaluated for 
effectiveness. The testing and evaluation has to be done with regularity depending on the 
associated level of risk but not less than annually so that effective implementation can be 
achieved. The standards and guidelines will provide consistency to the policies and 
procedures that are involved in detection, documentation and corrective action in 
response to an information security breach or mishap. These procedures also play a major 
preventive role in avoiding considerable denial of service or loss of data by mitigating the 
associated risks involved. 

L Gramm-Leach-Bliley Act of1999 (GLBA) P.L. 106-102 

The GLBA of 1999 replaced the Glass-Steagall Act of 1933 and allowed 
investment and commercial banks to consolidate and venture in the financial services 
industry. GLBA requires financial institutions to have a policy in place to protect the 
information from predictable threats and vulnerabilities in customer data security and 
integrity. GLBA compliance must be done whether the financial institution discloses 
nonpublic information or not. GLBA defines financial institutions as companies that offer 
financial products or services to individuals, like loans, financial or investment advice, or 
insurance. 

The GLBA has two key rules, the Financial Privacy Rule and the 
Safeguards Rule. The Financial Privacy Rule requires financial institutions to provide 
each customer with a privacy notice at the time the customer relationship is established 
and annually thereafter. The information collected about the consumer, where that 
information is shared, how that information is used, and how that information is protected 
should be thoroughly explained as required in the privacy notice. The privacy notice must 
also explain to the consumer of the opportunity to ‘opt-out’. GLBA defines opting out 
when the client refuses to give permission allowing their information to be shared with 
affiliated parties doing business with the financial institution. 

The Safeguards Rule require financial institutions to develop a written 

information security plan, practice and procedure that describes the company’s 

contingency plan in preparation and in the continued protection of their clients’ nonpublic 

personal information. The Safeguards Rule also applies to information of clients who are 
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no longer customers of the financial institution. This plan must include: (1) assigning at 
least one trained employee to properly manage the information security safeguards, (2) 
establishing a thorough and flexible risk management plan on each section or department 
that is handling and processing nonpublic information, (3) developing, monitoring, 
testing and evaluating the institution’s program to secure critical customer information, 
and (4) evaluating and modifying the safeguards as needed while conforming with the 
changes in how customer information is collected, stored, and used. 

The main intention of this rule is to do what current financial businesses 
should already to be exercising; which is protecting their client’s information through a 
robust information security plan. The Safeguards Rule mandates financial institutions to 
focus closely at how they process and handle private customer information and to follow 
guidelines and procedures to do a risk analysis on their current existing operation. Every 
financial institution has to show continuous documented effort to achieve GLBA 
compliance since no process is perfect. 

j. The Sarbanes-Oxley Act of2002 (SARBOX) P.L. 107-204 

Officially titled the Public Company Accounting Reform and Investor 
Protection Act of 2002, the SARBOX Act mandates financial institutions to improve the 
accuracy and reliability of their corporate and business disclosures in order to protect 
investors. The Act provides guidelines in the creation of a public company accounting 
oversight board, auditor independence, corporate and business responsibility and a more 
useful and accurate method of financial disclosure. 

The SARBOX Act requires a report of the internal controls that a financial 
institution has implemented to make certain that compliance to SARBOX is achieved. It 
is required in Section 404 of SARBOX that Chief Executive Officers (CEOs) and Chief 
Financial Officers (CFOs) must regularly file the Internal Control Over Financial 
Reporting and Certification of Disclosure in Exchange Act periodic reports. The 
Securities and Exchange Commission (SEC) has provided rules and guidelines on the 
proper content of these reports. Management is required to provide documentation and do 
an evaluation of the effectiveness of their internal controls over their financial reporting. 
Companies and businesses must provide proof of their internal control assessment 


16 



program, specifically documentation of their control procedures regarding their 
information technology systems. 

The security, accuracy and the reliability of systems that manage and 
report financial data is the responsibility of the company’s CIO. Enterprise Resource 
Planning type systems are intimately integrated in initiating, authorizing, processing and 
reporting of financial data. An established information security plan to periodically assess 
the overall financial reporting process together with other important processes of the 
company is required to make sure SARBOX compliance is achieved. The Act requires a 
fundamental change in business operations and financial reporting. Even though the CEO 
and the CFO are responsible to provide the corporate financial reporting, it is the CIO 
who plays a major role in the signoff of financial statements because compliance to the 
Act will ensure that the company’s information systems are providing correct data and 
analysis thereby making the financial reports more accurate and reliable. 


2. DoD IT Security Requirements 

a. DoD 5200.28-STD - Department of Defense Trusted Computer 
System Evaluation Criteria (TCSEC) 

The DoD 5200.28-STD was created by the National Computer Security 
Center (NCSC) to facilitate the widespread availability of trusted computer systems. In 
support of this goal the DoD Trusted Computer System Evaluation Criteria (TCSEC) was 
created, against which computer systems could be evaluated. The TCSEC was originally 
published on 15 August 1983 as CSC-STD-001-83. In December 1985 the DoD 
modified and adopted the TCSEC as a DoD Standard, DoD 5200.28-STD. 

TCSEC is a collection of criteria that was previously used to grade or rate 
the security offered by a computer system product. No new evaluations are being 
conducted using the TCSEC although there are some still ongoing at this time. The 
TCSEC is sometimes referred to as "the Orange Book" because of its orange cover. 

Under TCSEC, there are four levels that define criteria for trusted 
computer products. The four levels are A, B, C, and D. Level A, A1 being the highest, is 
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a system that can be proven through a mathematical model. Level B provides mandatory 
access control and require DoD clearance levels. Level C requires user log-on with a 
password discretionary access control and audit mechanism. Level D is a non-secure 
system. 

Paragraph 2.2.3.2.1 of TCSEC requires department and section heads to 
validate the work they accomplished in their system documentation by testing their 
security protection plans and procedures. This security testing would examine and 
document vulnerabilities that would result in the easy bypass of their security 
mechanisms, allow isolation anomalies on resources, and permit unauthorized access or 
modification to authentication or audit information 

b. DoDI 5200.40 -Department of Defense information Technology 
Security Certification and Accreditation Process (DITSCAP) 

The DoD Instruction 5200.40 (DITSCAP) is a standardized process 
defined by DoD designed for managing risk. DITSCAP establishes a standard DOD-wide 
process, set of activities, general task descriptions, and a management structure to 
achieve the certification and accreditation of DoD Information Systems (IS). This process 
will preserve the Information Assurance (lA) and security posture of the Defense 
Information Infrastructure (DII), which is now the Global Information Grid (GIG), 
throughout the life cycle of the system. 

The DITSCAP is designed to apply to any type of IT and any computing 
environment. It also applies to the acquisition, operation and sustainment of any DoD 
system that collects, stores, transmits, or processes unclassified or classified information 
since December 1997. The process can also be used for current existing systems 
certifications and other evaluated systems. It identifies four phases: System Definition, 
Verification, Validation, and Re-Accreditation, and uses weighted metrics to describe 
risks and their mediation. 

There are four major role players in the DITSCAP process namely, the IT 
system program manager (PM), the Designated Approving Authority (DAA), the 
Certification Authority (CA) and the user representative. The agreement between these 
four managers is very important in the success of the DITSCAP process. These managers 
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work as a team to resolve crucial schedules, financial concerns, security, functionality, 
and operational issues. The System Security Authorization Agreement (SSAA) is the 
document that contains this agreement. The SSAA is used to provide guidance and 
document the results of the DITSCAP process. The main goal of the SSAA is to be the 
binding agreement on the acceptable level of risk and security that is required before a 
DoD system development program begins or modifications to the system are completed. 

c. DoD 8500.1-STD - Information Assurance (lA) and DoD 
8500.2-STD - Information Assurance (lA) Implementation 

The DoD Directive 8500.1 mandates that “all lA and lA-enabled 
information technology (IT) products incorporated into DOD information systems shall 
be configured in accordance with DoD-approved security configuration guidelines”. The 
directive also tasks the Defense Information Systems Agency (DISA) to “develop and 
provide security configuration guidance for lA and lA-enabled IT products in 
coordination with Director, NSA.” The 8500.1 also requires the appointment of the DAA 
who is responsible and has the authority to accept the residual risk. 

The DOD Directive 8500.2 implements the prescribed guidelines outlined 
in DoD Directive 8500.1. DoD Directive 8500.2 provides guidance in achieving the 
application of an integrated and layered protection on the DoD information systems by 
implementing policies, assigning responsibilities and prescribing procedures in 
accordance with DoD 8500.1 

Directive 8500.2 requires the establishment of an information assurance 
program that evaluates security demands and performance thresholds. The development 
of the security design and configuration that conforms to a common architecture is the 
one objective of the IA program. Additional objectives of the IA program are 
implementing required controls or safeguards, the performing system tests and 
verification, and ensuring the appropriate use of life-cycle assurances such as 
configuration management. 

This instruction clarifies many different aspects of DoD lA controls and 
mechanisms such as access control, configuration management and audit. Striking a fine 
balance between the importance of the information and supporting technology to DoD 

operations require risk management. The presence of documented threats and 
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vulnerabilities, the reliability of the end users and interdependent systems and the 
increasing demands for personnel and financial resources is vital in balancing the 
importance of the information and supporting technology to DoD missions. Per this 
instruction, these critical DoD missions are to be safeguarded from the documented 
threats and vulnerabilities, the untrustworthiness of users and interconnected systems, and 
the capability of lA solutions make risk management more complex (DoDI 8500.2, 
2003). 

Risk management is the process if identifying, measuring, controlling and 
minimizing or reducing the security risk incurred by a system to an appropriate level with 
the value of assets protected. It is a complex process because of the presence of outsider 
and more importantly insider threat. It is difficult to identify dynamic insider and outsider 
threat to a system or network and determining the vulnerabilities that may be exploited by 
the threats to ensure an acceptable level of security is achieved. However this instruction 
guides the major proponents of information security on how to develop the necessary 
countermeasures to eliminate or reduce vulnerabilities to an acceptable level. 


3. Navy Medicine Command IT Requirements 

a. Military Health System (MHS) Information Assurance (lA) 
Policy/Guidance Manual version 1.3 2003 

The MHS lA Policy/Guidance was authorized by the Assistant Secretary 
of Defense for Health Affairs (ASDHA) and the Service Surgeons General. It was 
developed to address the consolidation of the MHS IT program development, 
management functions and personnel to improve efficiency and effectiveness. The policy 
guidance manual provides the requisite plans, procedures and direction needed to make 
sure that there are sufficient security safeguards that are enforced within the MHS to 
ensure compliance to the DoD’s Defense-in-Depth IA strategy. 

This guidance is the policy for all MHS centrally-managed Automated 
Information Systems (AISs) and networks under the authority of the MHS CIO. 
Additionally, this document is policy for the AISs and networks developed and operated 
by the TRICARE Management Activity (TMA) who is the lead agent for the MHS. 
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The stipulations in the manual covers all military, civilians and military 
contractors who are directly or indirectly involved in the management, design, 
development, operation, or acquisition or use of Tri-Service (centrally managed) AISs 
and networks. The manual also outlines the control of AISs and networks developed and 
operated by the TRICARE Management Activity (TMA). In addition, information 
systems that are Government Owned, Contractor Operated (GOCO) and Contractor 
Owned, Contractor Operated (COCO) that handle and manage DoD information are 
covered by the rules and regulations of this manual. 

The occurrence of major or significant changes on DoD information 
systems or its operating environment will be addressed by risk assessments. The 
discovery of network security threats and vulnerabilities will be done by doing 
penetration testing during the C&A process. This can be done on a regular basis or as 
required by the MHS lA Program office. The MHS lA Program office will be in charge 
in conducting penetration tests on DoD information systems. The Program Office will 
coordinate these tests with the respective MHS component of the different Services. This 
will ensure that sufficient appropriate security measures that are being used by the 
Services. 

The use of network vulnerability assessment tools on MHS components 
will be done to facilitate the identification of system and network vulnerabilities. Mission 
critical servers and networks will be annually evaluated by network vulnerability 
assessment tools. As part of the continuous C&A process, network vulnerability 
assessment software will be used on automated information systems and networks on a 
monthly basis. This assessment will be supervised by the MHS Component System 
Administrator and the Information Systems Security Officer. 

Events that threaten the MHS Component security of operations such as 
unauthorized intrusions, denial of service attacks, and service disruption incidents will be 
handled by using a comprehensive process that will audit, detect, isolate and react to 
these events. The analysis of audit records on the information systems at individual 
command MHS sites is required to be done monthly or more frequently when necessary. 
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The information system owners of each MHS component will perform regular security 
monitoring and weekly reviews of system records as part of their C&A process. 

b. Bureau of Medicine and Surgery (BUMED) Automated 

Information System (AIS) Security Program Policy Manual 

The Bureau of Medicine and Surgery (BUMED) directs the 
worldwide medical and dental services and facilities maintained by the Department of 
the Navy. The mission of BUMED within the national defense structure of the United 
States is to safeguard the health of Navy and Marine Corps personnel in the 
following areas: 

• Care and treatment of sick and injured members of the naval service 
and their dependents 

• Training programs for BUMED personnel 

• Continuing programs of medical and dental research 

• Prevention and control of diseases and injuries 

• Promotion of physical fitness of members in the naval service 

• Care for on-the-job injuries and illnesses of civilian employees 

• Supervision of the care and preparation for shipment and interment of 
deceased military members and of civilian personnel for whom the Navy 
is responsible 

Given this mission, the inherent sensitivity of maintaining the BUMED 
information systems become a critical issue by concerns for the privacy and integrity of 
the patient’s personal and medical information that is processed. Additionally, the 
availability of the health information systems that provide support in the delivery of 
quality access to care under Navy Medicine health care programs is also a critical 
management issue. 

BUMED is headed by the Chief of the Navy Bureau of Medicine and 
Surgery, who also serves as the Surgeon General of the Navy (N093). The Chief of 
BUMED and his staff is responsible for the promotion of quality health care for the 
patient and professional responsibility for the patient’s well being in Navy Medicine. 
The Chief of BUMED is responsible for providing high quality, economical health care 
to beneficiaries in wartime and in peacetime. BUMED provides highly trained Navy 
Medicine personnel that deploy with Sailors and Marines worldwide in providing critical 
mission support aboard ship, in the air, and on the battlefield. At the same time, BUMED 
Chief manages Navy Medicine's military and civilian health care professionals that are 
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providing care for uniformed services' family members and retirees at military treatment 
facilities around the globe. 

In his/her other capacity as the Surgeon General of the Navy (SG), the SG 
is the head of Medical Resources, Plans and Policy division (N0931) at the Pentagon. The 
SG implements the Chief of Naval Operations (CNO) responsibilities for provision of 
centralized, coordinated policy development, guidance, and professional advice on health 
care programs for DON. The Navy SG oversees the direct and indirect systems for 
providing health care services to all beneficiaries in wartime and peacetime as authorized 
by law. He/she also acquires sufficient resources to provide these services. 

The Navy Surgeon General’s staff at N0931 is responsible for the 
coordination and implementation of the Navy SG participation for resource requirements 
in the Navy’s Planning, Programming and Budgeting System (PPBS) process. The office 
of N0931 is responsible to develop balanced medical and dental programs within 
available resources, develop and evaluate plans and policy for medical support of general 
war and contingency operations. Under the leadership of the Navy SG, N0931 is tasked 
to develop and coordinate Navy and Marine Corps operational support requirements, 
establish and evaluate plans and policy in oversight and coordination of all aspects of 
deployable medical systems (DEPMEDS) and hospital ships. Furthermore, N0931 is 
directed to develop and evaluate policy in all aspects of medical research and 
development (R&D) initiatives consistent with operational support requirements and 
develop and assess legislative and policy initiatives involving issues related to Navy 
Medicine. 
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Figure 1. Chief of Naval Operations (CNO) Directorate 

[From 21] 



Figure 2. Chief of Bureau of Medicine and Surgery (BUMED) Directorate 

[From 21] 
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Figure 3. Surgeon General of the Navy (N093) Directorate 

[From 21] 

The BUMED Information Systems Security Program requires that 
information security protection mechanisms are enabled to defend BUMED AISs against 
the threat of unauthorized modification, disclosure, destruction, and denial of service in 
the entire phase of the system life cycle. The information security policy for the 
protection of medical data, access to care services, and health resources related to 
development, maintenance and operations involving the systems and networks in 
BUMED’s Claimancy 18 activities are established in this manual. Claimancy 18 
activities are approximately 390 medical and dental activities and commands that report 
directly to BUMED. 

The purpose of the BUMED security policy is to outline the security goals 
for Navy medicine patient and health provider data, medical services, and health related 
resources, i.e., those components of the BUMED systems and networks that require 
necessary privacy and security protection specially in accordance with the Health 
Insurance Portability and Accountability Act (HIPAA) regulations. The Program 
Managers, system designers, system administrators and helpdesk support personnel who 
are tasked to properly determine how to implement and enforce this security policy are 
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responsible for the specific implementation of security mechanisms, assurances and 
properties in the BUMED information systems. 

The objective of this policy is to assure that each automated information 
system (AIS) has the appropriate level of security that is equal or greater than the risk and 
degree of damage that could be a consequence from the unavailability, corruption, 
unauthorized exposure, or modification of the information or information systems that 
maintains the data. It is in the BUMED security policy that all Privacy Act information 
and HIPAA patient identifiable data (PID) be secured and protected at all times. This 
includes the collection of all rules, procedures, and business practices that regulate the 
manner in which the medical and dental treatment facility handles, safeguards, and 
disseminates their patient and provider health information. The utmost protection of the 
confidentiality, integrity, and availability of the medical information in each system’s 
level of security is a must. 

The BUMED Information Systems Security Policy serves as a 
comprehensive compilation of information security guidelines with which BUMED 
systems and networks must ensure compliance. This document provides direction to the 
BUMED information security program as it applies through every phase of the 
information systems life cycle. This policy also serves as the basis for further 
improvements of information security requirements on increasingly complex medical 
data that is used by Claimancy 18 activities and commands, and more importantly, this 
policy actively upholds the continuous certification and accreditation efforts conducted 
on BUMED information systems and network infrastructure. 
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III. CERTIFICATION AND ACCREDITATION 


A. THE CERTIFICATION AND ACCREDITATION PROCESS 

The DoD’s certification and accreditation process (C&A) is implemented in 
accordance with DoDI 5200.40, “DoD Information Technology Security Certification 
and Accreditation Process (DITSCAP). This instruction enforces the policies and 
guidelines as outlined in the DoDD 8500.1, “Information Assurance (lA),” Public law 
100-235 (1987), and Office of Management and Budget (0MB) Circular A-130, 
Management of Federal Information Resources.” All components of the DoD, its military 
contractors, and other personnel involved in DoD information systems are required to 
comply under this instruction. Furthermore, milestone decision authorities (MDA) use 
this document in the acquisition of IT resources, and for the procurement, handling, and 
life cycle maintenance of any DoD system involved in the collection, storage, 
transmission, or processing of different types of information. 

The goal of DITSCAP is to implement a systematized methodology to DoD’s 
certification and accreditation process. This document provides guidance in specifying 
necessary steps and procedures required to be addressed when evaluating a system for 
C&A. 
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Figure 4. DoD Information Technology Security Certification and Accreditation Program 

Overview 
[From 3] 
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The certification and accreditation process of is implemented in four phases. 
These phases are Definition, Verification, Validation, and Post Accreditation. The first 
phase in the process is Definition. The first phase focuses on comprehending the 
information system business case or system mission. The objective of the definition 
phase is to determines and agree on the system boundary, operating environment, security 
requirements, schedule, resources and the level of effort required. The creation of the 
initial draft of the System Security Authorization Agreement (SSAA) is incorporated in 
this phase. 
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Figure 5. DITSCAP First Phase Activities 
[From 3] 


There are three main activities in the definition phase. They are preparation, 
registration, and negotiation activities. The collection of all documentation and 
information involved in the system to be certified and accredited is accomplished in the 
preparation activity. The initiation of the risk assessment process involving the 
identification of security requirements, system boundaries and level of effort to ensure 
completion of the C&A process is accomplished in the registration activity. The 
negotiation activity confirms that the initial draft SSAA appropriately defines the level of 
effort for the system. This activity assures that the main proponents and other members of 
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the C&A team are thoroughly familiar with their roles and responsibilities in the 
DITSCAP process. The business mission and system information, operating environment, 
system security requirements, C&A boundaries, acknowledged security problems or 
discrepancies, and other security-relevant information are incorporated in the SSAA. 

The level of the certification effort is established by analyzing the business or 
system mission, functions, security requirements, architecture, and final end users. 
Documentation of this data will facilitate the analysis of the degree of confidentiality, 
integrity, availability and accountability that is deemed appropriate for the system. The 
level of certification effort is dependent on the level of confidentiality, integrity, and 
availability that is required of the system. The availability of this information provides 
the appropriate amount of assurance that the system will have full system functionality as 
defined in the system and security requirements It is necessary that the main proponents 
of the C&A process have full understanding that appropriate level of assurance necessary 
for the system requires the corresponding mandatory safeguards needed for system 
operation. The assurance of confidentiality means that the information is accessible only 
to those authorized to have access and that it is assured from destruction or corruption. 
The application of access control, cryptography, object reuse, physical security, 
emissions security techniques, administrative and engineering controls are several 
safeguard mechanisms that are used to enforce confidentiality. These protection 
mechanisms assist in preventing unapproved user control, hijacking, and electrical 
transmission. The preservation of integrity is accomplished by preventing the 
modification and deletion of information by unapproved users. Reliable integrity 
assurance mechanisms are access control, digital signatures, configuration control, and 
physical security. Availability is the degree to which the operation, data, infrastructure or 
system needs to be available as accessed by authorized users. The avoidance of denial of 
service attacks by unauthorized users is the main goal of availability. Several security 
mechanisms used to safeguard availability are restriction of access control, use of data 
backups and archives, modularity, redundancy and operations security (OPSEC). 

There are four certification levels of effort in the DITSCAP. The determination of 

the certification level of effort will dictate the amount and degree of analysis that will be 

done for the system. Selecting the appropriate certification level of effort is critical in 
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ensuring the proper implementation, security and requirements for the system. The 
certification level of effort indirectly determines the amount of resources that will be used 
in providing relevant information to the main C&A proponents. The Designated 
Approving Authority (DAA) will assess and evaluate the relevant data that is required to 
determine an informed accreditation decision. In each certification level of effort, a 
considerable amount of verification analysis is required to assure that the system behavior 
demonstrated conforms to the requirements definition specifications. Level one requires 
the completion of the minimum security checklist. This checklist can be found in 
Appendix 2 of the DoD 8510.1-M (DITSCAP Application Document). This minimal 
security activity checklist documents that the detailed concepts of system architecture, 
design (software, hardware and firmware), network connection rule compliance, 
integrity, life-cycle management, vulnerability assessments, system management, 
security test and evaluations, penetration testing, TEMPEST, and COMSEC requirements 
to the system have examined and reviewed to the fullest applicable level. The completion 
of the minimum security checklist is required in levels two, three and four. However, an 
independent, in-depth or extensive analysis of the system is also required. Determining 
the required analysis level of effort is accomplished by selecting alternatives for each of 
the key security-relevant characteristics that describes the system. Each characteristic has 
an assigned corresponding weight which is entered in the right column. The total of these 
weights is used to determine the appropriate certification level. 


Table 1. Certification Level of effort 
[From 2] 


Level 

Certification Level of Effort 

Description 

1 

Minimum Security Checklist 

Requires the completion of the minimum 
security checklist. The system user or an 
independent certifier may complete the 
checklist. This checklist can be found in 
Appendix 2 of DoD 8510.1-M, the 

DITSCAP Application Document. 

2 

Minimum Analysis 

Requires the completion of the minimum 
security checklist and independent 
certification analysis as defined in the 
verification and validation phases. 
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3 

Detailed Analysis 

Requires the completion of the minimum 
security checklist and more in-depth. 
Independent analysis as defined in the 
verification and validation phases 

4 

Extensive Analysis 

Requires the completion of the minimum 
security checklist and the most extensive 
independent analysis as defined in the 
verification and validation phases. 


Table 2. System Characteristics and Weights 

[From 2] 


Characteristic 

Alternatives and Weights 

Weight 

Interfacing Mode 

Benign (w=0). Passive (w=2). Active (w=6) 


Processing Mode 

Dedicated (w=I), System High (w=2), 
Compartmented (w=5), Multilevel (w=6) 


Attribution Mode 

None (w=0). Rudimentary (w=l). Selected (w=3). 
Comprehensive (w=6) 


Mission-Reliance 

None (w=0). Rudimentary (w=l), Selected (w=3). 
Comprehensive (w=6) 


Availability 

Reasonable (w=l), Soon (w=l), ASAP (w=3). 
Immediate (w=6) 


Integrity 

Not-applicable (w=0). Approximate (w=3). 

Exact (w=6) 


Information 

Categories 

Unclassified (w=l). Sensitive (w=2). 
Confidential (w=3). Secret (w=5). 

Top Secret (w=6), Compartmented / 

Special Access (w=8) 



Total of all weights 



During phase I of the process, a decision as to the certification level will be made 
and it is important to understand each factor of that decision. In determining the 
certification level, many factors are considered and given weights, these weights are 
added together to give the appropriate certification level. In some circumstances, the 
characteristics of a particular category might dictate a higher certification level than that 
indicated by the total weights. Among the four certification levels, the weights that 
identify each level overlap each other and might be an area of possible contention. This 
means that a level one or two, level two or three, level three or four certification could be 
required if the total weights fall into one of those ranges. This is where the negotiating 
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aspect of DITSCAP is employed. The main proponents of the C&A must collectively 
agree on the certification level of effort to be used on the C&A. This agreement is 
normally accomplished with the least amount of grief and anxiety among the C&A 
proponents. The proponents of the C&A have some latitude to add their own subjective 
opinion. This emphasizes the need for the proponents of the C&A to be equally prepared 
and experienced in order to know how to assist the DAA in making the appropriate 
decision. The DAA is also responsible for defining the accreditation requirements, 
obtaining a threat assessment for the system, assigning a Certifier to conduct the 
vulnerability and risk assessments, supporting the DITSCAP tailoring and level of effort 
determination, and approving the SSAA. The Certifier as well as the certification Team 
will support the DAA in any way they can with his/her responsibilities. 

The specific certification level of effort and documentation for certifying a system 
is at the discretion of the DAA. The decision of the DAA can be affected by several 
factors that can increase or decrease the degree of certification testing, analysis and 
documentation required. The degree of interconnectivity with other systems, the 
projected life expectancy of the system and the associated cost and investment on 
achieving the full level of certification effort associated with the C&A. The DAA will be 
the management official that will be responsible for accepting the risk. 


Table 3. DITSCAP Levels of Certification and Weights 

[From 2] 


Certification Level 

Weight 

Level 1 

If the total of the weighing factors are < 16 

Level 2 

If the total of the weighing factors are < 12-32 

Level 3 

If the total of the weighing factors are < 24-44 

Level 4 

If the total of the weighing factors are < 38-50 


The determination of the system’s security requirements are outlined in Task 1-5 
of the DITSCAP. The proponents of the C&A must examine the directives and security 
requisites to establish the applicable security requirements for the system. The 
certification team will focus on a section of the DODI 8500.2 for basic lA controls that 
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would subsequently be parsed into security requirements statements. The resulting 
security requirements will then be written into the Requirements Traceability Matrix 
(RTM) to facilitate the remainder of the C&A process. 

The RTM is usually in a spreadsheet format with an additional comment block for 
more specific details. The RTM conforms with the requirements through the System 
Security Requirements Specification (SSRS), and maps to the specific sections of the in 
the Certification Test and Evaluation (CT&E) procedures and the Security Test and 
Evaluation (ST&E) procedures where the requirement is tested. The type of assessment is 
indicated in the “Evaluation Method” column of the RTM. DITSCAP uses I=Interview; 
D=Document Review; T=Test; 0=Observation. The next block shows whether the 
requirement was met or not. The progress of the certification effort throughout the entire 
process is monitored by the C&A proponents by using the RTM. The RTM provides an 
excellent overview of the entire effort at the completion of the C&A and gives a quick 
snapshot of the completed and in-completed requirements. 


Table 4. Requirements Traceability Matrix 
The Chain of Traceability from Policy to Test Procedure 

[From 3] 


lAC Description 

Source 

Document 

Policy ID 

Test 
Method 
(I, D, T, 
O) 

Test 

Procedure 

ID 

Comment 

An annual lA review 
shall be conducted that 
omprehensively 
evaluates existing 
processes to ensure 
procedural consistency 
and to ensure that they 
fully support the 
goal of uninterrupted 
operations 

DoDI 8500.2 
Attachment 1 
to 

Enclosure 4 

Availability 

AV-1 

AV-5 

AV-7 

I 

TP-2 


The DoD information 
system security design 
shall incorporate best 
security practices such 
as single sign-on, PKI, 
smart card, and 
biometrics. 

DoDI 8500.2 
Attachment 1 
to Enclousre 

4 

Integrity 

IN-1 

IN-3 

IN-6 

IN-8 

I 

D 

TP-4 

TP-5 
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At the conclusion of the first phase, the C&A proponents will have a full 
understanding of the resource requirements needed in the C&A process. An agreement on 
the level of certification has been reached, as well as the requirements that will be tested 
and verified in the second phase. The main C&A proponents sign to acknowledge the 
SSAA with their signatures meaning that they have reached an agreement to satisfy and 
comply with these requirements. 


The second phase of the process is Verification. This phase begins with updating 
the SSAA as new system changes in the security requirements occur. The analysis of the 
system architecture, software design, network connection rule compliance, products to be 
integrated into the system, life-cycle management, security requirements validation 
procedures, and vulnerability assessments are included in this phase. 


Phase 2: Verification 
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Figure 6. DITSCAP Second Phase Activities 

[From 2] 

It is important that all the C&A proponents are aware of any adjustments made to 
the system because any change or adjustment can influence the scope of the C&A effort. 
The proponents must keep monitoring these changes to prevent failure in completing 
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their C&A process. The C&A team must not think that they have a limited role while the 
exact opposite is true. All the C&A proponents must be proactively involved in each 
phase as it implemented and enforced throughout the whole C&A process. 

The C&A process and security requirements analysis is performed to ensure 
adequacy and correctness. The analysis is also used to verify the relevance to the C&A 
process and conformity to the SSAA requirements. The C&A analysis will also confirm 
that the system design implementation satisfies the SSAA stated requirements as well as 
ensure the proper operation of the critical security components of the system. As the 
dimension and difficulty of the system under development changes so will the security 
requirements and the C&A effort. 

The certification process is examined to make sure that it is adequate. This 
evaluation of security requirements can result to the addition or deletion of requirements 
that were discussed in Phase One. The DITSCAP application manual lists seven initial 
certification tasks to be completed during the verification phase. They are (1) System 
Architecture Analysis, (2) Software Design and Analysis, (3) Network Connection Rule, 
(4) Integrity Analysis of Integrated Products, (5) Life Cycle Management Analysis, (6) 
Security Requirements Validation Procedures Preparation and (7) Vulnerability 
Assessment. 

The Certification Test and Evaluation (CT&E) is done to focus on a system’s 
security assessment irregardless of its business setting. This evaluation is often conducted 
in research laboratories. This allows for a more comprehensive and thorough testing of 
the system. It is during the CT&E that the security features in the system are verified with 
its technical security requirements. Generally, the Security Test and Evaluation (ST&E) 
occurs after the CT&E. This allows the system installation, integration and configuration 
for secure operations to be verified by the Certifier. It also sets up the opportunity for the 
Certifier to evaluate the security of the business setting and examine the capability of the 
ST&E test coverage. There are two pre-requisites before conducting the CT&E. First, the 
security features of the system must have configuration management control from the 
start of the CT&E up to the conclusion of Phase three. Second, there should not be any 
expected system changes before submission of system deliverables. 
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At the completion of the certification analysis, a well documented security 
specification, a comprehensive test plan and procedures and a document assuring that all 
network and network interface requirements have been determined, is prepared. The 
certification analysis outcomes are deliberated at the conclusion of each development 
stage. During the Verification Phase, the Task Analysis Summary Report and the 
evaluation and determination of system certification readiness is developed. The Task 
Analysis Summary Report uses the information from the SSAA, results from each 
certification task, discrepancy reports, system architecture and software design, and 
independent validation and verification reports as sources of input for each certification 
task. The output of the Task Analysis Summary Repot shows the record of findings, an 
evaluation of vulnerabilities discovered during system evaluations, a summary of the 
analysis level of effort, a summary of tools used and results obtained during the 
certification tasks and recommendations. 

Before proceeding to the actual Validation Phase, the knowledge that the system 
is ready to be certified has been determined. This means the system is assumed ready for 
testing of the fully integrated system in its hardware and software environment. System 
evaluation was done at each development step and inconsistencies and discrepancies 
discovered were identified by the C&A team and submitted to the main proponents of the 
C&A. This will enable the main proponents of the C&A to make necessary corrections or 
modifications. 

The DAA will be informed of any additional resources needed in the C&A 
process. Significant changes to the extent of the certification effort will result to require 
additional resources. 

During the Verification Phase, the regular review of the system to ensure its 
accordance with the SSAA is done by the DAA. The process of overseeing the system 
evaluation as well as analyzing the SSAA to ensure correctness in describing the system, 
threat, environment, security requirements, vulnerabilities to the system, and all other 
conditions in which the system will be operating is also the responsibility of the DAA. 
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Figure 7. DITSCAP Third Phase Activities 
[From 2] 


The third phase in the process is Validation. The validation of findings discovered 
in the Definition and Verification phases that contributed to the inception of an 
acceptable system. A system that performs within the specifications as stated in the 
requirements definition, and demonstrates the desired functionality and operability within 
an acceptable level of residual risk. 

During this phase it is imperative that the certifier and the C&A team closely 
collaborate throughout the entire C&A process and not only in one phase. The certifier 
and the team are major players in getting the C&A process to this point. They have 
provided critical input in determining the level of certification, determined the 
requirements to be tested on the system and provided valuable oversight to the system 
development process. 

By this time, the system to be accredited has already been integrated, and is 
awaiting the official accreditation decision. Again, the SAA will be reviewed, the 
integrated system will be evaluated, and the final accreditation decision will be made. At 
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the center of this phase is the System Test and Evaluation (ST&E). This set of actual test 
procedures are a detailed descriptions of the testing of security features to be performed 
during development. The ST&E is a detailed vulnerability analysis that is done during 
phase three. The goal of ST&E is to examine and analyze the security protection features 
required to safeguard a system as it is related to its business setting. The ST&E is a 
collection of actual test procedures used to determine the technical and non-technical 
security design features of the system. It is during the ST&E that the enforcement of 
important security features namely, intrusion detection systems, audit trails, contingency 
planning, physical and technical features of access control, anti-virus programs, 
automated security tools, procedures and policies are examined for conformity to the 
defined security design requirements. The C&A team makes every attempt to address and 
rectify security related discrepancies or vulnerabilities that are discovered during the 
ST&E. The outcome of the ST&E is an itemized report containing evaluation results, and 
data pertaining to the degree of residual risk. The extent of residual risk that remains after 
the security mechanisms have been enforced is called residual risk. It is very important 
that the Certifier, who is an experienced IA professional, properly compile the Test Plan 
and Procedures report. The report will be proof that the system had undergone meticulous 
testing with documentation that was proper analyzed. This report will assist the DAA in 
deciding the acceptable degree of residual risk to allow full system operation. The key in 
this phase is the residual risk assessment. 

The ST&E is performed during the evaluation to ensure that the security controls 
for the system are correctly implemented and working efficiently. The procedure 
describes the specific requirement based on the RTM. It also states the intention of the 
test, and outlines the success criteria. The DITSCAP application manual is a good source 
of examples on the proper format for each of the test procedures. Penetration testing, 
verification of TEMPEST compliance, communications security, system management 
analysis, site accreditation survey, evaluation of contingency plan and a risk management 
review are other testing areas required under DITSCAP. 

In addition to the ST&E, the C&A team needs to provide other pertinent 

documents. The Risk Assessment Report (RAR), Certification Evaluation Report (CER), 

and the Certification Statement. The CER contains the result of the certification testing 
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(ST&E). The CER also presents the comprehensive security test principle, the specific 
testing procedures and test results with comments. The RAR provides an in-depth 
analysis of the areas that were not successful in the ST&E. An analysis of threats, 
vulnerabilities and risk outcomes to the system are documented in the RAR report. For 
identified high risk concerns, the RAR describes the security weakness and defines the 
associated vulnerability. The RAR contains suggested countermeasures with 
corresponding risk reduction explanations. 

The results, observations and evaluations in this phase and the previous phases are 
compiled in a report for the DAA. The Certifier must disclose his observations and 
system accreditation recommendations to the DAA. Risk Assessment and Certification 
Evaluation Reports are developed and the certification statement is prepared. If the 
security requirements outlined in the SSAA were satisfied by the system then system 
certification is issued by the Certifier. This certification confirms that the system has 
properly complied to the system security requirements. Otherwise, if discrepancies 
remain yet the mission criticality requires system operation at an acceptable level of risk 
then the Certifier can issue an interim approval to operate (lATO). Correcting these 
deficiencies have a fixed time limit and are documented in the SSAA. 

The certification statement is the report to the DAA on the results of the 
certification testing. This report will include the recommendation to accredit the system 
or not, or to grant an interim approval to operate (lATO). A return to phase one 
renegotiation, then phase two and three would be the reco mm ended solution if the system 
still contains extremely high risks. This ensures repeatability is achieved in the C&A 
process. If the DITSCAP process was diligently followed by the C&A team and security 
experts then it is highly unlikely that a recommendation to disapprove an accreditation 
will ever happen. 

The documented system information and recommendation from the Certifier is 
now used by the DAA in reviewing the SSAA and arriving at a final accreditation 
decision. 
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Figure 8. DITSCAP Fourth Phase Activities 

[From 2] 


The fourth and final phase in the process is the Post Accreditation Phase. At this 
point the system has already been accredited and follows process activities that will 
operate and manage the system while maintaining an acceptable degree of residual risk. 
A system that is operating under an lATO will have to correct the system deficiencies 
that were discovered in phase three within a fixed amount of time. After the system is 
integrated into the operational computing environment and accredited, the system is 
monitored regularly to ensure that there are no significant changes to the configuration or 
environment that might affect the confidentiality, integrity or availability of the 
information contained. This monitoring is performed throughout the system’s lifecycle. A 
regular review to track system changes must be done to ensure that the system’s threat 
level will remain unaffected. Changes made must be controlled to preserve the stated 
configuration management requirements. Any changes made in the system can result in a 
change in the system’s security posture. Threats to the system mission, architecture, 
security policy, system risk, operational mode, audit results and sensitivity levels are 
some aspects that may cause change. The accreditation of the system is highly dependent 
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on the system configuration and the manner in which the system interfaces with its 
hardware and software components. Suggested future changes must be thoroughly 
reviewed by the proponents of the C&A to prevent the invalidation of the accreditation 
decision. The mitigation of possible system challenges as a result of system architecture, 
policy or design adjustments are handled using the risk management review process. 

It is essential that effective risk management review is conducted at this phase. A 
critical step in ensuring system security is the periodic evaluation of changing system 
threats. These system evaluations mitigate risk and provide valuable data in the system 
performance analysis. The continuous system operation within an acceptable level of risk 
is always maintained especially when the system security design and architecture is 
assessed against the security requirements defined in the SSAA. 

It is the responsibility of the Information System Security Officers (ISSO), the 
DAA, and system operators and administrators to maintain the security posture of the 
system. Re-accreditation will include the same procedures that were used to complete the 
original accreditation. However, valid sections of the original accreditation 
documentation need not be updated. Conducting on-site interviews enforces the 
effectiveness of a strong awareness program and information security training. It would 
also be recommended to the C&A team to conduct random spot checks on security 
procedures that were previously tested. 

1. Duties and Responsibilities 

The main proponents in the certification and accreditation process are the DAA, 
Certifier (CA), Program Manager (PM) and User Representative. The Information 
Assurance Officer (lAO) formerly known as the ISSO, the Information Assurance 
Manager (lAM) formerly known as the ISSM and the System Administrator are 
privileged users with lA responsibilities that support the main proponents of the system’s 
C&A process. It is very important that the DAA, PM, user representative, lAO, lAM and 
system administrators all perform their jobs to the best of their ability. This will ensure 
that re-accreditation after three years will be less stressful and there is greater assurance 
that the system life cycle will be more secure. An informed proactive posture to 
information security certification and accreditation will maintain public and Government 
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trust in the agency’s ability to conduct business while avoiding undesirable and 
unnecessary information security mishaps. 

DITSCAP allows other roles to be added to support the overall decision process 
and mission. DITSCAP permits the establishment of certification teams under the 
certifier’s supervision to extend assistance to the certifier in the performance of the actual 
security testing. The Program Manager and lAO are major players in the C&A process. 
Each of these roles greatly affects each phase of the process. These roles are responsible 
for deciding the range of the effort as it pertains to the system mission, resources, 
architecture and environment. The members of the C&A team must collaborate to ensure 
that the project stays on schedule, complies with design implementation, and adequately 
handle possible threats to the system. During Phase one of DITSCAP, it is very important 
that all roles in the certification effort come together and collectively expound on the 
security requirements, scope, and certification level of effort. This exchange of ideas 
should result to a final consensus by the members of the C&A team. 

The DAA is the senior management individual who is responsible for making sure 
that the system functions within an acceptable level of risk. The DAA is the person with 
the positional authority to fully accredit the system. As a member of the agency’s upper 
management and it is their responsibility to evaluate the agency mission and available 
resources for the system to be accredited. The DAA has to have the authority to accept 
the risk. The extent of acceptable residual risk depends on numerous factors, most 
important is the mission criticality. The accepted residual risk may be significant 
depending on the importance of the mission. It is pertinent to comprehend that the 
management has the ultimate decision and many internal and external factors may 
influence this decision. 

The Certifier is the person responsible for making sure that the DAA receives 
sufficient pertinent information concerning the involved risks. The Certifier is the 
technical expert in the certification process and provides the necessary technical 
information needed by the DAA. It is the Certifier’s prerogative to execute the C&A 
process with a team. The Certifier ensures that the proper documentation of the security 
requirements noted in the SSAA. The appropriate level of residual risk is recommended 
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by the Certifier. The Certifier develops the accreditation package and submits the 
accreditation recommendation to the DAA. 

The Program Manager manages each aspect of the system from the original 
concept, to the development, implementation, and system maintenance. The program 
manager is responsible for the system throughout its entire lifecycle, and is responsible 
for ensuring the security requirements are implemented correctly. The PM has the 
ultimate responsibility for the overall acquisition, evolution, incorporation, alteration or 
operation and maintenance of the system. The PM ensures the use of cost-effective lA 
standards to the program by using appropriate resources and setting priorities. 

The User Representative is concerned with the system’s confidentiality, integrity, 
availability, access, functionality and performance as it relates to the ultimate mission of 
the system. The user representative represents the operational interests in the system user 
community and assists in the certification and accreditation process by helping to define 
the system operations and functional requirements. He/she provides input for system 
mission use requirements and SSAA input in the data sensitivity and end-user 
functionality sections. 

Information Assurance Manager (lAM) is operational system’s technical security 
expert. He/she is an advisor to the DAA. The lAM is responsible for creating and 
managing the information system’s security program. The I AM performs tracking and 
incident reporting, system vulnerability assessments, routine audit trail reviews, and 
regular reporting of systems security condition. The lAM is a key player in the 
establishment and authorization of the SSAA. He/she facilitates and oversees the 
performance of numerous lAOs (CJCSM 6510.01, 2004). 

The Information Assurance Officer (lAO) is responsible for monitoring and 
maintaining the security of the system as defined by the SSAA, as well as ensuring that 
the system follows all security requirements as stated in the documentation. The lAO 
reports the security status of the IS to the lAM, as required by the DAA. The lAO 
maintains the System Security Plan (SSP) and ensures TEMPEST measures are enforced. 
In addition, the lAO conducts user training and awareness activities under the supervision 
of the lAM (CJCSM 6510.01, 2004). 
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The System Administrator (SA) is responsible for the proper operation, 
maintenance and disposition of the systems in agreement with the security policies and 
practices as defined in the C&A package. The SA enforces proper authorization, security 
clearances, need-to-know for all users before granting access to the systems. He/she 
reports all security related incidents to the ISSO, maintains and documents configuration 
management (CM) for all security relevant IS assets. The SA is also responsible for the 
monitoring of system recovery process and the proper restoration of the systems security 
features and procedures when needed. 

The management of each aspect of the system life cycle starting from its original 
concept, to the development, implementation, and system maintenance is the Program 
Manager’s responsibility. The program manager is responsible for the system throughout 
its entire lifecycle, and is responsible for ensuring the security requirements are complied 
and properly implemented. 


B. XACTA CERTIFICATION AND ACCREDITATION SOFTWARE 
SOLUTION 

1. System Name and Identification 

System Name: Xacta Information Assurance (lA) Manager Enterprise Edition 

V4.0 

System ID: Xacta lA Manager Enterprise Edition V4.0, Xacta Assessment 

Engine. 

2. System Description 

The Xacta lA Manager Enterprise Edition is a private-owned, Commercial-off- 
the-Shelf (COTS) based information security risk management software application. 
With Xacta lA Manager, the C&A team defines the network or system configuration and 
the environment in which it operates, and the application automatically engages the 
appropriate security requirements according to government and/or industry best practices. 
The software then automatically generates the appropriate test procedures, processes the 
test results, produces a risk assessment, and allows the user to automatically publish a 
complete C&A package, including all appendices, in accordance with the National 
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Institute of Standards and Technology (NIST), the Department of Defense Information 
Technology Security Certification and Accreditation Process (DITSCAP), the National 
Information Assurance Certification and Accreditation Process (NIACAP), or the 
Director of Central Intelligence Directive (DCID). Through the software’s automation of 
these formal processes, organizations can validate their compliance to Govern m ent and 
DoD mandates, such as the Federal Information Security Management Act, Health 
Insurance Portability and Accountability Act, Gramm-Leach-Bliley Act, Sarbanes-Oxley, 
Privacy Act of 1974, DITSCAP and DCID 6/3. In addition to traditional security 
assessment and compliance, the software provides Continuous Assessment of the 
network and system security posture to ensure emerging threats are mitigated prior to an 
attack. 

The Xacta lA Manager is a comprehensive solution for IT security administrators 
that manage risk, sustained compliance, vulnerability management and remediation 
through the use of cutting edge automated security methods. It merges the industry¬ 
leading compliance and risk assessment features with effective mission process 
integration technology to create a centralized security management platform that 
facilitates and enhances compliance assessment, constant risk and routine compliance 
management, and security process enforcement. 

After being acquired by numerous federal agencies and commercial enterprises, 
Xacta lA Manager enables its users to enforce continuous risk and security compliance as 
well as initiate corrective actions automatically that are necessary in the protection 
mission essential systems. 

The Xacta lA Manager was developed and released by Xacta Corporation, a 
Northern Virginia-based security software company. It was originally developed as Xacta 
Web C&A to address the need for standards-based security assessment and was further 
developed to Xacta Commerce Trust, a continuous enterprise risk management product. 
By leveraging Xacta Web C&A’s and Xacta Commerce Trust’s architecture and the 
knowledge base the company created to support the system certification and accreditation 
needs of the federal marketplace, Xacta developed the lA Manager which is enables 
information security-conscious corporations and organizations to achieve more than 
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minimum compliance and demonstrate a more proactive, enterprise-wide posture in 
conducting and executing risk management. 
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Figure 9. Xacta Web C&A and Xacta Commerce Trust Architecture 

[From 18) 


Established in February 2000, Xacta Corporation employs approximately 120 
professionals across the country with principal business offices in the Washington, D.C. 
and New York City areas. Formerly part of the e-solutions division of Telos Corporation, 
Xacta is now organized as a wholly owned subsidiary of Telos, one of the premier 
suppliers of network integration and systems development solutions to the Department of 
Defense and civilian agencies. 

Xacta Corporation, a Telos company, develops, markets, and sells government- 
validated secure enterprise solutions to federal, state and local agencies, as well as to 
commercial customers. Xacta’s offerings include enterprise IT security management 
solutions, enterprise security consulting services, enterprise messaging, secure wireless 
networking, and high assurance credentialing solutions 

Telos Corporation has provided innovative IT solutions to the federal government 

for more than 30 years. The company provides systems integration and value added 
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reseller solutions to U.S. government customers. Telos and Xacta Corporation, its 
subsidiary for security solutions, have been ensuring that the government’s most 
demanding and security-conscious organizations comply with existing and emerging 
information security mandates since 1989. 

a. System Diagrams 

Figure 11a high level graphical representation of the overall architecture 
of the Xacta lA Manager Enterprise Edition. The Xacta lA Manager is an information 
security risk management application that consists of the Application Server, Detect 
Server, Publishing Server, and Graphical User Interface (GUI). 



Figure 10. Xacta lA Manager Enterprise Edition Architecture Diagram 

[From 18) 


Figure 12 is the Xacta lA Manager Process Enforcement Architecture. The 
Xacta lA Manager delivers an IT enterprise-level toolkit with secure management 
functionality. The lA Manager provides (1) an executive level reporting and management 
tool that displays key information, (2) process automation modules providing role-based 
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processes and audit trails and (3) content adapters that facilitate and coordinate the staff 
and their work with lA-related services such as enterprise management systems, resource 
applications, internet security software, security management software, databases, secure 
email and messaging. 
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Figure 11. Xacta lA Manager Process Enforcement Architecture 
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3. Functional Description 

a. System Capabilities 

The Xacta lA Manager helps the C&A team accelerate the organization’s 
regulatory compliance and reporting. Some of the features and benefits that Xacta lA 
Manager provides (1) an essential capabilities necessary for the analysis of the 
organization’s information security, (2) a Policy Locking and Enforcement feature where 
the C&A team can identify the organizations best security practices and implement these 
practices during the risk assessment and management process, (3) a checklist-based 
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security requirements which fill in the Security Requirements Traceability Matrix 
(SRTM) or related methods that need requirements mapping, (4) a Formal Test Plan that 
is generated dynamically designed to address system specific requirements and SRTM 
elements (5) an automated and streamlined presentation of the C&A process in 
accordance with federal and commercial regulatory requirements, including agency 
specific content and templates. 

The Xacta lA Manager Upgrades provide additional C&A functionality to 
provide a more comprehensive solution in the secure management of the IT enterprise. 
Some of the key features of the Xacta lA Manager Upgrades are (1) a continuous 
collection of relevant configuration information on IT assets that enable the C&A team to 
regularly manage their risk and compliance posture to comply for constant C&A and risk 
assessment monitoring, (2) a method to capture Xacta’s best business practices and 
assessment methodologies using the built-in wizard-driven templates that facilitate and 
clarifies C&A compliance assessment, (3) an automatic update feature on current 
vulnerabilities that provides continuous information on IT security threats and 
recommends real time corrective action with increased response time to counter possible 
threats, (4) an automatic information gathering utility that monitors critical shifts in the 
IT network environment, (5) a vulnerability and requirements based calculator that 
dynamically adjusts the IT enterprise risk and compliance posture. 

The Xacta lA Manager Process Enforcement Upgrade delivers (I) a 
comprehensive, coordinated and automated risk management and remediation 
methodology for cross-enterprise deployment, (2) an automatic critical response system 
that triggers corrective action to address known vulnerabilities, inform essential 
personnel and log help desk trouble calls, (3) a software patch management system that 
automatically distributes and installs critical updates across the enterprise to ensure a 
current and updated security posture. 

The Xacta lA Manager is supported by a unique collection of C&A 
technologies as shown in Figure 13. 
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KdCtd lA Han^dAr intIudeSi 

A&sGSiniAnt EriginA - Software designed bo automate various IT security risk arid compliance assessment 
business functions. 

H&[>E [irtcluded forfrae] 

M5DE is included with Xacta lA Nanartier — no need to purchase n database r&r standalone low volume 
deployiTients. Also supports Oracle and M5 SQL ror larger or enterprise deployiTients. 

Risk and Coinplia 1106 Process Eit^ine 

Software application that automates various aspects or comprehensive risk and compliance assessment 
processes such as ISO 17795, DOD BSdd, NIST 505^57, and DQD 

Risk and CumpliaiiCA AssessruArTt WArhflow 

Distribute Specific risk and compliance assessment Functions across multiple people. 

ChACklist-based Test Pla it 

Security requirements provided in checklist Format allow for quick cciTipllance audit and no need for Forrrial 
test pnocedures. Suitable For some low-impact, non-sensitive and non-mission-critical systems. 

Fomtal Ta^ pi Alt 

Complete test plan with comprehensive se-ourity requirements and corresponding test procedures. Suitable For 
s&nsitiueand mission-critical systems and low-impact systems. 

security Standards dnd Regulations Libraries 

irtcludes more than 5, odd individual testable requirements to include I'nost DOD and civilian a^ei^cies as well 
aiVISA, GL&A, HIPAA., and iso 177S9. 

RA|>orting and Nnlificadon Engine - Connprehensiveset oFIT security management tools as well as risk and 
compliance reporting necessary to address a wide range oF government and commercial regulatory mandates. 

Regulatdry CompliancA Reports 

Automated publishing engine that produces doeurrients necessary for various comnnercial^ international^ and 
U.5. government regulatory compliance reporting [e.g., 15Q 17799^ QQ]> S^OO, NI5T SOO-37^ and DGQ 0/2], 

PrdjACt IMartageniAnrt RAporis 

Detailed reports to help organizations monitor and manage the status of on-gning risk and compliance 
assessments. 

IT ASfAt/lrtvArrtAry RAparts 

Rich set of asset data assembled via the xacta [>etect utilities provides eatensive asset inventory and 
vulnerability management reporting capability (approximately 50 standard reports). 

AjutoitnatAd E-mail Event NAtfficatioits 

Most valuable when xacta lA Managei is deployed as an enterprise solution or when used in workgroup or 
collaboration-mode. Ptogrammabie business rules that make it possible ror xacta lA r^ianager to notiFy a 
human being (via e-mail) for exception handling or when something requires human attention. 

xarta [>At«rt - integrated set or IT asset and vulnerability collection utilities designed to automate the 
inFormaLion gathering and security testing processes. 

Automatic VulnArability FAAd and Filter 


Understjrxl how new vuln^rabliltlH potential ly effect yojr systems. 

Slitlc/ContlnuouB Host Scinnlng 

AvdllatHe as an enecutable to collect entenslv e security Conflgurat-lon Intofmatlon on yaur twit macbires, or as 
an active agent that auboniatically collects ujodated inrormatfon at pfogrammable time Intervals. 


Figure 12. Summary of Xacta lA Manager features 

[From 18] 
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CAittinuOu:S utjliti£& d^i^rl-QCl to dutomMfi 

certain risk and compliance assessmeirit business functions. 

V 


InFdrmalion Readers (.xls^ .xinl) 

import assei information automatically via sprea-daneois and xmil-IOrinatLed 
documents. 

✓ 


Vulh Arabi lity Scan ner 

Java-bas&ci scanner witn more than 3^000 plugins mat are updated weekly. 



Discii^very Scanner 

NMAP-like runctionality. 

✓ 


InTormation imp^ort Bridges 

Automatically import asset and vulnerability inforination From otner systems such 
as SMS, Tivoli, I5S Scanner, and others. 

/ 


Autoinatie Prograrmnable Scaniiiiig 

Perform various collection and scanning 'functions to update risk and compliance 
nosture at prociramrriable intervals fcasecl on time or eveiit triooers. 

/ 


Automatic Recalculatian of Risk and Compliance 

Uodated asset iiiforination used to recalculate risk and comoliance. 

/ 


Automatic Event NotiflicatiOiiis 

Notify users Of important events regarding new devices, vulnerabilities anevor 
risk/compliance tolerances being exceeded. 

/ 


Process Enforcer Upgrade - Continuous Assessment Functionality plus 
integrated IT security process automation and iotegratioii technology designed to 
autoiviate and accelerate sec-urity manaciement Functions, including vulnerability 
remediation. 

/ 

✓ 

Business Process Automatimi 

Synchronize security management business process across an entire 
organization. 

/ 

✓ 

Business Process Iniegratioit CompOfients 

interface with other business systems that support the security management 

process (e.g., help desk, enterprise management s^ysteins, etc.) 

/ 

✓ 

Business Prticess Designers 

Ousckiy riiudirv and/Ur add automated business functions. 
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Business Process Hdhitor 

Real-time view of busineis brccesi Flows, fstatus, txittleriecks-. etc .) 

/ 
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Figure 13. Summary of features for Xaeta lA Manager Upgrade and Proeess Enforcer 

Upgrade 

[From 18] 
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SupiKprt FAdtur«4 


Coiit«iirt Updat«e 

Up^ldt-QS t£> ^11 Support^ r^gul-dtions^ r^quir^merits, and ^band^rds. Automattcally upd^t^^ ■datal>a&& via 
xatta Actrvg Update. 


Active Ui^date 

Automatic CO nt^it update in^charism (standards, ro^ulatiorK, requirements, vulnerability scanner pluq-ins, 
etc.j 

Xacta Forurii hES 

xada-h^^^teJ user qrOup bulle^ri board System. 

EQQ Help Support 

Unlimited product support. 


E-mail Customer Care Support 

Obtain product support via e-mail as well a*telephone. 

Vu liierabilitv See finer Plu^*in Updates 

Vulnerability Scanner Plug-in Updates (new plug-ins issued at least weekly)^ vulnerability intelligence alert 
reeds^ and hostinfO updates. 

User Training 

user training included witli rrwst xacta lA Manager purctiases. 


Figure 14. Summary of features for Xacta lA Manager Support Features 

[From 18] 

b. System Classification 

The intent of this section is purely informational and not marketing. The 
purpose of the data is to inform potential C&A users that the Xacta tool is certified under 
the Common Criteria. This information is not intended to persuade but inform potential 
C&A users of the facts related to the certification of the Xacta automated C&A tool. 

In accordance with the Common Criteria (CC) for Information 
Technology Security Evaluation, Version 2.2, January 2004 (CCV2.2) ISO/IEC 15408 
and Common Methodology for Information Technology Security Evaluation, Version 
2.2, Evaluation Methodology, January 2004 (CEMV2.2), which is now the National 
Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation 
Scheme for Information Technology Security, this system is has been certified as an 
Evaluation Assurance Level 2 (EAL2). This system has been evaluated at CygnaCom 
Solutions, an accredited testing laboratory. The Xacta IA Manager’s functional and 
assurance security specifications are contained in its security target. The evaluation has 
been conducted in accordance with NIAP CC Evaluation and Validation Scheme and the 
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conclusions of the testing laboratory in the evaluation technical report are consistent with 
the evidence presented. 

The Common Criteria are standards for evaluating security software against 
vendor claims or user requirements. Evaluation is done by approved private laboratories 
and is recognized by multiple nations. The program is overseen in the United States by 
the NIAP, a joint effort between the National Institute of Standards and Technology 
(NIST) and the National Security Agency (NSA). Common Criteria certification for 
security products is required by the Defense Department, and on national security 
systems in the federal government. 

c. Classification and Sensitivity of Data Processed 

Information that is stored, processed, and transmitted on, through and/or 
from Xacta lA Manager is considered Sensitive But Unclassified and should be marked 
as For Official Use Only (FOUO). All FOUO data is protected by measures appropriate 
for unclassified system high operations. Controls for need-to-know information are an 
element of the protective mechanisms placed on Xacta lA Manager. All system 
administration information contained in Xacta lA Manager Application Server is under 
the cognizance of the Xacta built-in Master Administrator.. 

d. System User Description and Clearance Levels 

The Xacta lA Manager Enterprise Edition has a web based graphical user 
interface through which all Xacta lA Manager Enterprise Edition functions are managed. 
It supports four roles, built-in master administrator, administrator, executive and user. A 
primary function of the application administrator is to create security assessment 
“projects”, create “user” accounts for persons who will work on those projects, and 
assign the users to the appropriate projects (based on a project role). As a way of 
managing or grouping accounts and projects, the administrator has the option to segregate 
these accounts and projects objects into “folders”. Security policy settings for usernames 
and passwords are established through the GUI. Also, administrators use the GUI to 
enable or disable audit logging and to review and archive the audit trail. The Built-in 
Master Administrator and Administrator accounts use the administrator Interface. 

Normal user login results in the presentation of a list of projects to which a 
user has been assigned. The user’s access to projects is based on their assignment to 
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specific project roles within a project. (More than one user may be assigned to any 
particular role within a project.) The primary functions a user executes within the 
application include the following tasks: 

• Requirements & Definition: the user describes the security boundary of a 
particular automated information system (AIS) and identifies the security 
requirements that it will be evaluated against 

• Inventory & System Information: the user identifies all components within 
the system boundary and provides other detailed project information 

• Vulnerability Assessment & Testing: the user completes checklists, 
prepares test plan documentation, and enters test results 

• Analysis and Reporting: the user performs in-depth analysis of risks 
identified for the system and completes required deliverable 
documentation. 

Each of these tasks is executed through a series of process steps. Based on 
the particular role to which a user has been assigned, not all of these tasks will be visible 
(or accessible). The arrangement of “Tasks” and “Process Steps” within any project is 
customizable and may vary from one project to the next. (Customers may also define 
agency-specific workflows and disseminate these in the form of a project template.) Both 
the Executive and User accounts use the User Interface. 
e. Life Cycle of the System 

Xacta lA Manager is in the implementation and maintenance stage of its 
life cycle. It is an information risk management application project funded by the Telos 
Corporation. Its purpose is to streamline the organization’s C&A and continuous risk 
assessment, automate security business processes across the enterprise, provide full 
automation support for numerous federal, DoD and civilian compliance standards, and 
perform comprehensive IT management. It utilizes patent pending technologies that 
enable the creation and maintenance of a continuous sequence of automated IT security 
processes configured to the enterprise specific requirements. 

The configuration and operation of Xacta lA Manager conforms to the life 
cycle design and execution strategy required for all federal, DoD and civilian owned 
information systems. 
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f. Minimum System Requirements 

The minimum system requirements for Xaeta lA Manager inelude 
produets formerly known as Xaeta Web C&A and Xaeta Commeree Trust. 

Assessment Engine - Single Server Deployment 
The single-server installation is recommended for small networks 
or for a standalone system typically employed by those performing static compliance/risk 
assessments. The following are the minimum requirements for a single-server 
installation: [From 18] 

Server/Desktop/Laptop 

• Pentium 4 (2 GHz Processor) 

• 1 GB RAM 

• 40 GB Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 

• MSDE or MS SQL Server 2000 (Service Pack 3 or above) or 
Oracle 8i/9i/10g 

• MS Windows 2000 Server/Pro or MS Windows XP Pro or MS 
Windows 2003 Server 

Assessment Engine - Standard Network Deployment 
The standard multi-server installation is recommended for 
medium-sized enterprises or regional installations that are part of a larger distributed 
installation. The recommended configuration for a standard network deployment consists 
of two server-class machines: an application server and a database/publishing server. The 
following are the minimum requirements for a standard network installation: 

Application Server 

• Pentium 4 (1.8 GHz Processor) 

• 2 GB RAM 

• 40 GB Hard Drive 

• MS Windows 2000 Server or MS Windows 2003 Server 


Database - Publishing Server 

• Pentium 4 (1.8 GHz Processor) 

• 2 GB RAM 

• 60 GB Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 
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• MS SQL Server 2000 (Service Pack 3 or above. When using SQL 
Server, approximately 120 GB of database storage space will need 
to be available) or Oracle 8i/9i/10g 

• MS Windows 2000 Server or MS Windows 2003 Server 

Assessment Engine - High Volume Network Deployment 
The high-volume multi-server installation is recommended for 
enterprises that have a large number of projects and wish to maintain centralized control 
over the data. The recommended configuration for a high-volume network deployment 
consists of three server-class machines: an application server, a database server, and a 
publishing server. The following are the minimum system requirements for a high- 
volume network installation: [From 18] 

Application Server 

• Pentium 4 (2.4 GHz Processor) 

• 2 GB RAM 

• 40 GB Hard Drive 

• MS Windows 2000 Server or MS Windows 2003 Server 
Database Server 

• Pentium 4 (2.4 GHz Processor) 

• 2 GB RAM 

• 120 GB Hard Drive 

• MS SQL Server 2000 (Service Pack 3 or above; when using SQL 
Server approximately 120 GB of database storage space will need 
to be available) or Oracle 8i/9i/10g 

• MS Windows 2000 Server or MS Windows 2003 Server 

Publishing Server 

• Pentium 4 (1.8 GHz Processor) 

• 1 GB RAM 

• 40 GB Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 

• MS Windows 2000 Server or MS Windows 2003 Server 

Microsoft (MS) Office Installation 

The Xacta Publisher component requires all MS Word files and libraries 

to be installed. 
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The minimum system requirements for Xacta lA Manager Continuous 
Assessment Upgrade include the Xacta Detect Server and Client. The Xacta Detect 
Server is a network and vulnerability scan engine. It is included in the Professional 
Edition as a standalone client-server scanner. In the Enterprise and Process Enforcement 
Editions, the core Assessment Engine controls the Xacta Detect Server in Continuous 
Assessment mode. Multiple Xacta Detect Servers can be installed to accommodate 
segmented or distributed networks. [From 18] 

• Xacta Detect Server is supported on MS Windows 2000 Server/Pro 
and MS Windows XP Pro. 

• The Xacta Detect Client is a networked GUI client that can be installed 
on any MS Windows platform. 

Access Requirements: 

• Microsoft Internet Explorer 6 or Netscape Navigator 7 

• TCP/IP connection to the application 

• Access to a printer 

• Adobe Acrobat Reader 5.0 and above 

Recommended Installation and Administration Skills: 

• MS Windows 2000, XP and/or 2003 administration skills 

• MS SQL Server or Oracle database administration knowledge 

• General Internet and TCP/IP networking knowledge 

The minimum system requirements for Xacta lA Manager Process 
Enforcer Upgrade are: [From 18] 

Server Platforms: 

Windows: 

• Pentium 4(1.8 GHz Processor) 

• 2 GB RAM 

• 40 GB Hard Drive 

• MS Windows 2000 Server/Pro or MS Windows XP Pro 

• 240 MB disk space for a full installation of Process Enforcer 

• Minimum 500 MB temporary space free on the drive to be used for 
installation 

• DBMS: MS SQL Server 2000 SP3 or Oracle 8i or 9i. 
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UNIX 


• HP-UX 11.0 C class or better (PA RISC 2) (400 MHz Processor) 
or Sun Solaris 2.8 

• 2 GB RAM 

• 40 GB Hard Drive 

• 240 MB disk space for a full installation of Process Enforcer 

• Minimum 500 MB temporary space free on the drive to be used for 
installation 

• DBMS: MS SQL Server 2000 SP3 or Oracle 8i or 9i. 


Client Platforms 

Process Enforcer Design Console: 

• Pentium 4 (600 MHz Processor) 

• 512 MB RAM 

• MS Windows 2000 Server/Pro or MS Windows XP Pro 


Task Manager and Report Tool: 

• Pentium 4 (600 MHz Processor) 

• 512 MB RAM 

• MS Windows 2000 Server/Pro or MS Windows XP Pro 


The minimum system requirements for Xacta lA Distribution 
Manager are: [From 18] 

• Pentium 4 (2 GHz Processor) 

• 1GB RAM 

• 60 GB Hard Drive 

• MS Windows 2000 Server, MS Windows Server 2003 

• MS SQL Server 2000 SP3 or Oracle 8i/9i/10g Server 

The following are the network and client minimum system requirements 
needed to access and use the Process Enforcer Task Manager, Process Enforcer Report 
Tool and/or Distribution Manager: 

• Microsoft Internet Explorer 6 or Netscape Navigator 7 

• TCP/IP connection to the Xacta Process Enforcer application server 

• TCP/IP connection to the Xacta Distribution Manager application 
server 

• TCP/IP connection to the Xacta lA Manager Assessment Engine 
application server 
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The following are the recommended installation and administration skills 
for Process Enforcer and Distribution Manager: 

• MS Windows 2000, XP and/or 2003 server administration skills 

• HP-UX 11.0 administration skills or Sun Solaris 2.8 administration 
skills (Process Enforcer only) 

• MS SQL Server or Oracle database administration knowledge 

• General Internet and TCP/IP networking knowledge 


4. Xacta Graphic User interface (GUI) 
a. Using the Application 
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Figure 15. Application Interface 
[From 18] 

1. Item A, the Menu Bar is located at the top of the screen and contains the 
following menus and links: 

• The Resources menu opens a window containing links to the Assessment 
Engine Reference Manual (in .pdf format) and to the Adobe website where 
Adobe Acrobat Reader can be downloaded. 

• The Preferences menu opens a window containing options to set user 
preferences. 

• The Settings menu, visible only to a master administrator, opens a window 
from which all system settings can be accessed. 

• The About menu opens a window containing information about the 
version number of the application, as well as the license agreement and 
credits. 

• The Logoff link is used to log out of the application. 

2. Item B, the Page Title is located below the Menu Bar and displays the 

title of the page you are currently viewing. 
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3. Item C, the Message Area is located directly below the Page Title area 
and dynamically displays informative messages based on your actions; such as Save 
confirmation, errors, status information, and tips. 

4. Item D, the Left Navigation Bar is located on the left side of the screen 
and is used to navigate through the application. 

5. Item E, the Action Bar is located below the Message Area and contains 
action buttons for the page you are viewing. 

6. Item F, a Help button is located to the right of the Page Title area. This 
help is context-sensitive and displays help pertaining to the current page. If you need 
additional assistance, you can view the entire application reference manual in .pdf format. 
The Assessment Engine Reference Manual is found under the Resources menu at the top 
of the screen. 

7. Item G, when working on a process step, the Previous Step and Next 
Step buttons are displayed on the Action Bar (they are not displayed in the diagram 
because a process step is not open). These buttons are used to quickly move to the next 
process step or return to the previous process step. 

8. Item H, the Content Area occupies the majority of the application 
screen and contains all the input fields and data relevant to the current page. 

9. Item I, the Status Bar displays the account name and type of account 
currently logged in the lower-right comer of the screen. 
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b. Preparing Assessment 
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Figure 16. Adding Project 
[From 18] 
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Figure 17. Logging Customer Service Center 
[From 18] 
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Figure 18. Allocate Products to Users 
[From 18] 
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Figure 19. Entering Subscription Key to Assessment Engine 

[From 18] 



Figure 20. Selecting Template 
[From 18] 




nH^TQM^ Hrmi ri^Ui n 

AAEiuUi ^-liraiirLiri 


- j:i 


--^rt 



Figure 21. Creating Folder Level Accounts 
[From 18] 
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Figure 22. Creating Roles 
[From 18] 


c. Performing Assessment 
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Figure 23. Task Page and Task State 
[From 18] 
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Figure 24. Project Definition 
[From 18] 
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Figure 25. System Security 
[From 18] 
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Figure 26. Requirements Questionnaire 

[From 18] 
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Figure 27. System Security Requirements 

[From 18] 
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Figure 28. Security Requirements Traceability Matrix 

[From 18] 
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Figure 29. 


Equipment Inventory 
[From 18] 
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Figure 30. Minimum Security Checklist 
[From 18] 
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Figure 31. Test Plan and Results 
[From 18] 
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Figure 32. Security Test and Evaluation 

[From 18] 
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Figure 3 3. Certification Results 
[From 18] 


69 









































Figure 34. Analysis of Risk Elements 
[From 18] 



Figure 35. Plan of Action and Milestones (POA&M) Elements 

[From 18] 
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Figure 36. Reports Overview 
[From 18] 



Figure 3 7. Proj ect Tracking Report 

[From 18] 
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Figure 38. Compliance Report 
[From 18] 
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Figure 39. Requirements Report 
[From 18] 
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Figure 40. Risk Report 
[From 18] 

C. ENTERPRISE MISSION ASSURANCE SUPPORT SYSTEM (EMASS) 
CERTIFICATION AND ACCREDITATION SOFTWARE SOLUTION 

1. System Name and Identification 

System Name: Enterprise Mission Assuranee Support System - Next Generation 

System ID: eMASS-NG 

2. System Description 

The Enterprise Mission Assurance Support System - Next Generation (eMASS- 
NG) is a government-owned, Commercial-off-the-Shelf (COTS) based solution, which 
seamlessly integrates several capability models to support Information Assurance (lA) 
program management needs. eMASS-NG is fiilly compliant with the concept of lA 
controls-based information assurance, and is intended to provide full support of the 
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Department of Defense (DoD) 8500 series, National Institute of Standards and 
Technology (NIST) Special Publication (SP) 800-37/800-53, and Director of Central 
Intelligence Directives (DCID) 6/3 enviro nm ents. 

The Enterprise Mission Assurance Support System (eMASS) was originally 
developed as a Research and Development (R&D) prototype - this version was labeled 
Release 2.0. The eMASS development continued to Next Generation, which will be used 
by DoD, Civil, and Federal agencies alike. 

At its core are a flexible Relational Database Management System (RDBMS) and 
a clear, easy-to-use web interface driven by decision wizards to perform complex 
functions and data analysis. Additionally, other core modules will consist of ports and 
protocols management, vulnerability management, configuration management, lA 
architecture and asset management, and other policy compliance with Defense 
Information Systems Agency (DISA) Standard Technical Implementation Guide (STIG) 
and National Security Agency (NSA) Security Recommendation Guides (SRGs). 

eMASS-NG is designed to operate in a secure intranet, such as a logically isolated 
Non-classified Internet Protocol Router Network (NIPRNet) enclave or a Secret Internet 
Protocol Router Network (SIPRNet) enclave. The application is enabled with Public Key 
Infrastructure (PKI), and all data in transit, at rest, and on backup media is fully 
encrypted. eMASS-NG will provide a secure web-based system for lA professionals to 
automate all aspects of enterprise-wide lA planning and operations including decisions, 
workflow, configurations, and relationships. 

a. System Diagrams 

Figure 16 depicts a high level graphical representation of the overall 
functionality of eMASS-NG once it has been fully developed. Figure 17 depicts the C&A 
architecture of eMASS-NG. 
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Figure 41. eMASS-NG Functionality 
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Figure 42. eMASS-NG C&A Architecture 
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3. Functional Description 

a. System Capabilities 

eMASS-NG will allow users to enter system information, track the 
progress of the information assurance activities (such as: validation tests, compliance 
statuses, artifacts, etc.) and associated action plans for the purpose of sharing system 
security information and compliance status. This system will be designed to allow 
members of the DoD community to track accreditation of their component systems, and 
provide the status of their system vulnerabilities to controlling authorities. 

b. System Classification 

The intent of this section is purely informational and not marketing. The 
purpose of the data is to inform potential C&A users that the eMASS tool is classified as 
a Mission Assurance Category (MAC) II, Sensitive. This information is not intended to 
persuade but inform potential C&A users of the facts related to the classification of the 
eMASS automated C&A tool. 

In accordance with DoD Instruction 8500.2, this system is classified as a 
MAC II, Sensitive. This system is important to the support of deployed and contingency 
forces. The consequences of loss of integrity are unacceptable. Loss of availability is 
difficult to deal with and can only be tolerated for a short time. The consequences could 
include delay or degradation in providing important support services or commodities that 
may seriously impact mission effectiveness or operational readiness. MAC II systems 
require additional safeguards beyond best practices to ensure assurance. 

c. Classification and Sensitivity of Data Processed 

Information that is stored, processed, and transmitted on, through and/or 
from eMASS-NG is considered at least Sensitive But Unclassified and should be marked 
as For Official Use Only (FOUO). All FOUO data is protected by measures appropriate 
for unclassified system high operations. Need-to-know controls are an element of the 
protective measures placed on eMASS-NG. All system administration information 
contained in eMASS-NG is under the cognizance of the eMASS-NG Program Manager. 

eMASS-NG is capable of profiling the certification status of Defense 
Information Systems Network (DISN) systems. The resulting map and profiles of DISN 
systems would be a valuable resource for both internal and external threat exploitation. 
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Exploitation of this information and/or penetration of the DISN could lead to the 
following: 

• Unauthorized access to DoD information assets. 

• Manipulation of information for unauthorized purposes, including 
personal gain. 

• Accidental or intentional denial of services attacks to DoD information 
assets. 

• Wrongful disclosure of sensitive certification and accreditation 
information. 

The following matrix describes the functional data category (e.g., e-mail, 
network management traffic, personnel transactions, financial transactions), the data 
target (receiving application), the classification and sensitivity of the data (e.g., 
Unclassified, Privacy Act, Financially Sensitive, Proprietary, Administrative/Other, 
Confidential, Secret, Top Secret, Compartmented/Special Access), the user clearance 
level required for access, the data source (originating application), and the transmission 
mode (e.g., Internet, Web, File Transfer Protocol (FTP), Telnet, Stand Alone, Manual 
Procedure, Value Added Network(VAN)). For transmissions outside the boundary of 
this SSAA, the matrix also includes the protection measures in place and the accreditation 
status of interfacing systems or networks. 

Table 5. eMASS-NG Data Type and Flow 


Data 

Category 

Receiving 

System 

Data Type 

Clearance 

Level 

Data 

Source 

Transmission 

Mode 

Protection 

Mechanism 

C&A 

Status 

Connectivity 

WAN 

Administrative 

Non¬ 

sensitive 

N/A 

Intranet, 
LAN, WAN 

Network 

Perimeter 

Components 

Unknown 

Firewall Logs 

Cisco PIX 
Firewall 

Administrative 

Non¬ 

sensitive 

Firewall, 

Internet 

Internet, Web, 
FTP, Telnet, 
Stand Alone, 
LAN, VAN, 
WAN 

Network 

Perimeter 

Components 

N/A 

Intrusion 
Detection 
Log File 

Router, 
Cisco PIX 
Firewall, 
IDS 

Administrative 

Non¬ 

sensitive 

Internal/ 

External 

Networks 

Intranet, 
Internet, Web, 
FTP, Telnet, 
LAN, VAN, 
WAN 

Network 

Perimeter 

Components 

N/A 

Network 

Management 

Traffic 

Router, 
Cisco PIX 
Firewall, 
IDS 

Administrative 

Non¬ 

sensitive 

Internet, 

Web, 

FTP, 

Telnet, 

LAN, 

VAN, 

WAN 

Internet, Web, 
FTP, Telnet, 
LAN, VAN, 
WAN 

Network 

Perimeter 

Components 

N/A 
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d. System User Description and Clearance Levels 
The users of these systems ean be divided into four groups: 

1. Guest User - An individual who is granted access to the system login page 
and has the ability to register for access. 

2. Registered User - An individual who is granted access to the system. 

3. Administrator - An individual responsible for the configuration of the 
eMASS-NG system for a specific server box. This individual will be 
assigned the responsibilities of defining the organizational hierarchies, 
role/permission groupings, workflows, and system settings. 

4. Primary Author - An individual who is responsible for managing the 
documentation of a system. This individual will be assigned the 
responsibilities of editing controls, editing validation tests and editing 
expected results. 

A user profile and a role must be created for every user within the 
eMASS-NG instance in order for them to access eMASS-NG. The system registration 
process begins when a user accesses the eMASS-NG public site and creates a user 
profile. Once the user has entered the required information, this data is passed to the 
system and appears on the workload of the system administrator. The system 
administrator must then manually verify that the user requesting access to eMASS-NG 
has been assigned a role by the organization’s approval authority. If so, the system 
administrator activates the user and sends a response to the user, indicating that their 
account is now active. If the user has not been assigned a role, the user must wait for their 
role to be assigned. If the organization’s approval authority denies a role assignment to a 
user requesting access, the system administrator will deny the registration request and 
notify the user that their request was denied. 

The clearance level of this system is unclassified. All users of this system 
will have the proper level of security clearance to operate, at a minimum, in a user 
capacity on the system. Additionally, all users have the appropriate clearance level to 
perform their specific duties. Federal employees have undergone the appropriate hiring 
screening process associated with their position. Contractors are required to complete a 
Standard Form 86 from which a National Agency Check with Inquiries (NACI) is 
conducted. 
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e. Life Cycle of the System 

eMASS-NG is in the development stage of its life cycle. It is an R&D 
project funded by the Office of the Assistant Secretary of Defense Networks and 
Information Integration (ASDNII). Its purpose is to provide full automation support for 
the next generation of information assurance policy, the DoD 8500 series. It utilizes 
DoD’s proven e-business automation techniques to take information assurance 
management to the next level. eMASS-NG is an enterprise-wide solution for lA 
management. 

The configuration and operation of eMASS-NG conforms to the life cycle 
design and execution strategy required for all DoD owned systems. The acquisition, 
installation, and testing of appropriate security software were accomplished followed by 
system, security, and user application testing and acceptance. eMASS-NG will be 
subjected to a periodic Security Readiness Review (SRR) process to ensure the integrity, 
confidentiality, availability, and accountability of the system and its data. 

f Minimum System Requirements 

eMASS-NG is configured using Microsoft Windows 2000 and UNIX 
based servers to support web access from DoD approved web browsers hosted on 
appropriately managed client workstations. 

Network Deployment 

The following are the minimum hardware requirements for an 
eMASS multi-server installation: 

Load Balancer 

Catalyst Switch 

8 Port Fiber Channel Switch 

Power Vault Storage Area Network (SAN) 

Cisco Pix Firewall 

(Two) Web Servers functioning as UNIX servers. 

• Dell PowerEdge 2650 with 2 Intel Xeon Processors (2.0-3.2 GHz) 
with hyper threading support 

• 1 -12 GB PC266 ECC DDR SDRAM RAM 
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• Raid Controller Embedded dual channel Ultra 3 (U160) SCSI with 
128 MB cache 

• 730 GB (5 X 146GB) Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 

• MSDE or MS SQL Server 2000 (Service Pack 3 or above) or 
Oracle 8i/9i/10g 

• MS Windows 2003 Server 

• Windows External Connector 

• Crystal Reports 10 

Database Servers 

• Dell PowerEdge 2650 with 2 Intel Xeon Processors (2.0-3.2 GHz) 
with hyper threading support 

• 1 -12 GB PC266 ECC DDR SDRAM RAM 

• Raid Controller Embedded dual channel Ultra 3 (U160) SCSI with 
128 MB cache 

• 730 GB (5 X 146GB) Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 

• MSDE or MS SQL Server 2000 (Service Pack 3 or above) or 
Oracle 8i/9i/10g 

• MS Windows 2003 Server 

Desktop/Laptop 

• Pentium 4 (2 GHz Processor) 

• 1 GB RAM 

• 40 GB Hard Drive 

• MS Office 2000, MS Office XP, MS Office 2003 

• MSDE or MS SQL Server 2000 (Service Pack 3 or above) or 
Oracle Client 9.2 

• MS Windows 2000 Server/Pro or MS Windows XP Pro or MS 
Windows 2003 Server 

The following are the minimum software requirements for an 
eMASS multi-server installation: 

eMASS Web Servers functioning as UNIX servers. 

• MS Windows 2000 Advanced Server, SP4, SSL connection, using 
Kernel Modes 

• MS DotNet Framework, SPl, Standard, Not Kernel Mode 

• MS IIS Diagnostics, 1.0, Standard, Not Kernel Mode 

• Crystal Reports, 10, Standard, Not Kernel Mode 

• Symantec Antivirs, 8.1, Standard, Not Kernel Mode 
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eMASS SQL Stage Server 

• MS Windows 2000 Advanced Server, SP4, SSL connection, using 
Kernel Mode 

• MS DotNet Framework, SPl, Standard, Non Kernel Mode 

• MS IIS Diagnostics, 1.0, Standard, Non Kernel Mode 

• MS SQL Server, SP 3a, Standard, Kernel Mode 

• Symantec Antivirs, 8.1, Standard, Non Kernel Mode 

eMASS SQL Web -Enabled Database Server 

• Oracle Client, 9.2, Non Kernel Mode 

• Oracle Universal Installer, 2.2.0.12.0, Standard, Non Kernel Mode 

• MS Windows 2000 Advanced Server, SP4, SSL connection, using 
Kernel Modes 

• MS DotNet Framework, SPl, Standard, Non Kernel Mode 

• MS IIS Diagnostics, 1.0, Standard, Non Kernel Mode 

• MS SQL Server, SP 3a, Standard, Kernel Mode 

• Symantec Antivirs, 8.1, Standard, Non Kernel Mode 

eMASS Oracle Server 

• Oracle Client, 9.2, Kernel Mode 

• Oracle Universal Installer, 2.2.0.12.0, Non Kernel Mode 

• MS Windows 2000 Advanced Server, SP4, SSL connection, using 
Kernel Modes 

• MS DotNet Framework, SPl, Standard, Non Kernel Mode 

• MS IIS Diagnostics, 1.0, Standard, Non Kernel Mode 

• MS SQL Server, SP 3a, Standard, Kernel Mode 

• Symantec Antivirs, 8.1, Standard, Non Kernel Mode 

• Sun J2EE SDK, 1.4, Standard, Non Kernel Mode 

• WinZip 8.1, Standard, Non Kemal Mode 


4. eMASS Graphic User interface (GUI) 
a. Getting started with eMASS 

The creation of user accounts allow users to access the eMASS system. It 
is the responsibility of the system administrator to approve and register new accounts in 
the eMASS system. The system administrator also maintains existing accounts that allow 
users to access the system and modify user profdes as necessary. 
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Figure 43. eMASS New User Registration 
[From 16] 

After the eMASS welcome banner screen, a standard security alert and a 
client authentication screen appears. eMASS uses Public Key Infrastructure (PKI) for 
authenticating its users. 


Client Authenticatian 


^2£l 


r Identfficaftion" 




The Web site you want to view requests identification. 
Select the certificate to use when connecting. 


Test. User. 1. Valid 


More Info... View Certificate... 


OK I Cancel | 


Figure 44. eMASS User Account Client Authentication (PKI) 

[From 16] 
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***** UNCLASSIFIED ***** I 

Enterprise Mission Assurance Sii|)pDrt Sptern 


■» 


* ». 

Welcome ' 



eMASS User Registration 


Certificate ID: sa 

salutation or ntJe: 
eg; col, sgC Me, Dr. 

«■ First Name: 


hi: 

" Last Name; 
' Grade: 
Position: 
' User Phone: 
Entail Address: 
* Organization; 


Te&t 


Department of Defense 


Priv4c^ StotemEiit | Acxessibility | Security Notice 


LJlMCLASSlFltn 


Figure 45. eMASS User Registration Applieation Form 

[From 16] 


UNCLASSIFIED 



t’M ASS ^terpHse Mission Assurance Support System 



Welcome ' 



Your registration information has been captured successfully^ 

A system administrator wili review your application. 



Privacy statament | Accessibility | Security Not]« 




UNCLASSIFIED 


Figure 46. eMASS User Registration Confirmation 

[From 16] 
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This \$ a Department of Defense computer System rniis computer system, including an 
reiafea equipment network^ and networft devites (s^peciftcally Inclu-ding Infennel access), ane 
provided <3fily for authorized U S Government use 

OOD Q omputer systems may be monitored for alt lawtUt purposes. Inciuding to ensure that 
their use is authomed for management of me system to facilitate protection against 
un^uttionzed access, and to verify secuniy procedures, survivaPiltty and operational security 

Momionng includes aclive atlacKs by autnorized OOD entilies to tester verify the security oT 
this system During monitoriiig. inronmatiCNJi may E>e eicamined. recorded, copied and used for 
authpriEed purposes All intonnation. including personal information, placed on orsert over 
this system may be monitored 

Use of this DOD cornpuler system, auinonzed or unauthorized, constitutes consent to 
momtonng of inis system Unauirtonzed use may subject you to cmninal prosecutjon. Evidence 
of unau[nonz:eci use ccHi^cted during moniionng may De used for adminisifaiive. enminat or 
adverse action. 

use of this system c emstrtutes consent to moriitormig tor Uiese puiposes. 



Update Certificate 


PVrvflcy Subamml | Ac^cessiuliy | Securfy h 


Figure 47. eMASS Existing User Account Banner 

[From 16] 



Edit User Profile 


Dlstirguished Wanne: C=US, 0=U.S. GovernmentH OLI=DoO, OU=PfCl, 0U=O 
Salutation or Title: 

eg: col, sgt^ Mr,, or, 


n First Name: 

Mt: 

h Last Name: 
■ Grade: 
Position: 
' User Phone; 
K Email Address; 
A organliatton: 


Program Manager 


1(202)321-7054 

Ijohn.doeOl-dod.iT 


I Department of Defense 


Subirut Can<c:el 


Seojntv Nctiee I Privacy Statement | Aag«ibilitv Statement 


■uiii r iJiy^H 3BTi 


Versten 0.4,15 


Figure 48. eMASS Existing User Edit Profile 
[From 16] 
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Figure 49. eMASS Navigating Workload Tasks 

[From 16] 

b. eMASS Controls Administration (CAM) 

The eMass Controls Administration Module (CAM) permit users to (1) 
author and manage information assurance (IA) control sets, subject areas, and controls 
applicable to the following levels: the DoD Enterprise, the DoD Component, or the DoD 
Information System, (2) attach implementation guidance to lA controls as reference 
material while implementing C&A, (3) author generic validation procedures and 
expected results for lA controls and (4) generate controls reports to identify residual risk 
or areas requiring remedial action. 

Instruments that measure lA condition of integrity, availability or 
confidentiality are called lA Controls.. These controls are achieved through the 
application of safeguards or regulation of specific activities. The control conditions are 
testable and compliance is measurable. The necessary activities required to achieve 
implementation of the lA control are assignable and accountable tasks. 
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May Apply to 
New lA Control 
or Supplement 
an Existing 
lA Control 


Figure 50. eMASS Role of Information Assurance (lA) controls 

[From 16] 


Subject AreaSj 


1. Security Design & 
Configuration 

2. Identification & 
Authentication 

3. Enclave & Computing 
Environment 

4. Enclave Boundary 
Defense 

5. Physical & 
Environmental 

6. Personnel 

7. Continuity 

8. Vulnerability & 
Incident Management 



Figure 51. eMASS IA Controls MAC and Confidentiality 

[From 16] 
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Test.User. 1. Valid 

c'MASS ^terprise MTssioft Assurance Su p port System 

Control Adm inistration _ 

\ Manage ComroTs KfflffilBSWSIESSKffflil! 


****■*■ unclassified ***** 

, Hom« ReiHrts Wqdll^d H elp Edit Proftle Lchgout 

; ^ \y 


ge St^ject Areas | 


Search Controls 


Create Ctjntrol 


Controls include processes and methodologies that must be followed to provide Information Assurance (lA) for 
government Owned systems* For every control there may be a list of Validation Tests that provide personnel with 
an explanation of how to verify compliance with each control and the test scripts that they should use to test 
system compliancy. For each Validation Test there may be Expected Results that describe the results that should 
come from the successful implementation of Controls. 


Control Set! |dq 0I SSoo.a 




subject Area: 


Enclave Boundary Defense 

Enclave computing Environneot 

Identifrcation and Authentication 


d 


Attiibutes: e>od confidentiality: F Public F sensitive F classified 

MAC: rar 2 r 3 


Control Acronym: 




COA5- 
COAS-2 
COBR-1 ^ 

^ Detailed View ^ Summary View 


Figure 52. eMASS Managing and Searching for Controls 

[From 16] 


Test.User Invalid 

tMASS Enterprise MIssicmi Assurance Su p port Systiem 


Control Administration 


UNCLASSIFIED _ 

i Home Reports Wor^pod j Hdp ! Edit Profile Layout 


^ 1 



Manage Controls 


Create Control [ 

The system found I Controls matching your search criteria. 


To view a Control, dick on the Control Acronym from the results below. _ 

Delete? Acronym Name_Descriptio-n_Attributes_ 

A comprehensive account management process is implemented 
to ensure that only authorized users can gain access to 

F lAAC-1 Account Control woricstatians, applications and networks and that individual DqD Confidentialtty: Classified, Sensitive 

accounts designated as inactive, suspended, or terminated are 
pfompdy deactivated. 


F 


lAGA-1 

Group 

Identification and 

Group authenticators for application or network access may be 
used onFy in conjuction with an individual aumenticator. Any 

use of group authenticators not based on the DoD PKI has been DoD Confidentialrty: Classified, Sensitive 


Authentication 

e^cplicitiy approved by the Designated Approving Authority 
(DAA). 


Page: 1 


Delete Checked Control 


Seojirty Notice | Privecy Statement | Acceatbility Statement _ Vensiori 0-4. iO 


UNCLASSIFIED 


eMASS Managing and Searching for Controls (continued) 
[From 16] 
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Test. User. 1. Valid 


‘ UNCLASSIFIED **■*• 



Figure 53. eMASS Managing and Creating a Control 

[From 16] 
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est.UsBr.l.V^lid 


' UNCLASSIFIED ' 


'^IWASS E»^terpri^ Assurance Sy p ftort System 

ontrol Adm inistration 

Cortifob L^.f=i ir- [.£^^.; ■ I.f j mu r-i ii^ 


Home Reports Wcr^lBsd Help ^ Etfit profile 


Control Viewi hgjj 


COPY 


Creato validation Teat 


aim 


hgjj dfgh control Sot: DODI S500.2 Version: l.DO 

Start Date: 2005/03/02 Eitpiration Date: Recertification Period: 365 

Functional Area: control Description: tneyteythgidfh 

Subject Area I Continuity Attiibutes: 


Delate cofitrol 


Adding Validation Test 
Fields fn BOLD are required. 

Test Acronym: hg))-F 
Test Name: | 


Fields in BOLD are required. 

rest TETT-Ol-fl" 

Test Nain^: | 

Test Description: 


■ 3 ] 


Test Preparation steps; 


Test Execution Steps; 


Commencs: 


States; lor^ft 

Status D^te; I 


^-1 

Expected Result Acronvm: reTT-Oi-i- 1^ 
Expected Result Description: 


mon-dd-yyyy 

- H 


save Validation Test 


Figure 54. eMASS Creating a Validation Test 
[From 16] 
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Test.User.l, Valid 
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rIVIASS Enterprise; Mission Assurance Support System 

Home Raparts Hflfp 

Edit Profiliir Lotjout 

Control Administration 

: 



Manage Cciitrots 


Manage Qintroi Sets 


Manage St^ject Areas | 


Control Sets 

Create Control Set 


Controls are logically grouped into Control Sets. Control Sets may represent an entire Guidance Authority such 
as the DoD S5l0. 

To view a Control Set^ selea the Control Set Name from the results below. 



^ Maine 

OescHp^tioil 

r 

AR2S-5Q 

Controls identified by the Army Regulation for InPoimatiPn Assurance 

r 

OCIP 6/3 

Controls eKtracted from the Director of Central Intelligen-ce Directive 6/3 

r 

OpPI ssoo-j 

A list of controls as deRned within OoPI 850D.2 Enclosure 4 

r 

Mr. KrinMe 

Helo Mn Krinkle Ho-w are you today? Seems the rumors are about your team might move away Now, me I'm sentimental But 
I'm not one to cry say there Mr. xhnide let’s cruise the eastord boat Damn then sonsabitches wvith their gill-nets set afloat J 
Flip on my tele and I watch the waters die Cmon Mr. Krinkle tell m« why Hey ho Mr. Krinide have you heard the bfand new 
sound It's a cross between Jimi Hensfnx Bocephus, Cher and James Brown It's called 'Tleavy Hometown" New Wave, cold- 
filtered, tow-calorie dry c'mon Mr. Krintde tell me why 

r 

MI5T 8Q0-5J A list pf tho CPOtrolS identified by NrST SP 000-53. 


r Set iName This is a Test conducted by Kje3ly Byrd. This is only a Test. 11 
KgLLV BVRp 


Detete checked control set 


Figure 55. eMASS Managing Control Sets 
[From 16] 


TestUser.l.Valld 

***** UNCLASSIFIED 

***** 

/MASS Enterprise Mission Assurance Support System 

. 4 

Feme Repoftr Help Edit Prurfrlc Lofiput 

Control Administration 

•# 


Manage ConEielS Manage Subject Areas ] 



Update Control Set 


Control Set Name: 

Policy: 

Description: 


[Do&Ti^QoT 

IdcPI 8E00.2 

ft list of controls as dsFined within Pool 8500.3 3 

Erclosure 4 




Subject Area: 


Attributes: 



Figure 56. eMASS Updating Control Sets 
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Figure 57. eMASS Creating Control Sets 
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c. eMASS Certification and Administration Module 
The eMASS C&A Module provides users access to (1) view systems 
within eMASS with which the user has appropriate access, (2) Register new systems 
following the IT registration process, (3) Monitor and manage controls and their 
corresponding validation procedures and (4) Interact with systems as they go through 
workflow process. 
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Figure 58. eMASS Certification and Accreditation (C&A) Accessing 

Existing User Accounts 
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Figure 59. cMASS Certification and Accreditation (C&A) Home Page 
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Operations Planniing System 
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Agency 
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Application 

Distribution 
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03/04/2006 

ORRS 1 

DRRS 

Department of 
Defense 

AIS 

Application 


Auttionty To Operate 
(ATO) 

03/03/2006 

ELTS 

Electronic Logistics Tracking 
System 

Defense Logistics 
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AIS 
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03/03/2006 

KB I 
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Defense 

AIS 
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Authority To Operate 

(ATO) 

03/04/2006 


Page: 1 


Figure 60. eMASS Certification and Accreditation (C&A) System Listing 
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Figure 61. eMASS Certification and Accreditation (C&A) System Main Page 
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Figure 62. eMASS Certification and Accreditation (C&A) Register System 
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Figure 63. eMASS Certification and Accreditation (C&A) Selecting Guidance Authority 
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Figure 64. eMASS Certification and Accreditation (C&A) Selecting Additional Control Sets 
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Figure 65. eMASS Certification and Accreditation (C&A) Selecting Additional Control Set 

Selection Criteria 
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Figure 66. eMASS Certification and Accreditation (C&A) Adding and/or Upgrading 

Assigned Controls 
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Figure 67. eMASS Certification and Accreditation (C&A) Set Inheritability 

[From 16] 



Figure 68. eMASS Certification and Accreditation (C&A) Entering System Architecture 

[From 16] 
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Figure 69. eMASS Generating Common Reports 
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Figure 70. eMASS Report Customization 
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eMASS Report Customization (cont’d) 
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Figure 71. eMASS Report Customization Export 
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IV. RESEARCH FINDING AND ANALYSIS 


A. INTRODUCTION 

The key objectives of this analysis are to (1) describe exactly what capabilities 
and functionalities that the automated C&A tools provide to the main C&A proponents, 
especially assisting the DAA, in making an informed accreditation decision, and more 
importantly, (2) analyze and understand lA controls and use mapping techniques to 
demonstrate evidence that the lA controls were being satisfied regardless of the C&A 
process. The recognition of these objectives will reinforce the relationship of the 
standardized DoDI 8500.2 lA controls structure as a basis for lA C&A. This 
understanding will provide valuable insight to further expand the knowledge base of the 
Navy Medicine DAA in authorizing the operation of mission essential Navy Medicine 
health information systems and managing lA posture across Navy Medicine based on 
consistent lA controls. 

The analysis for this study was done utilizing two methods. In the first method, a 
limited number of Navy Medicine lA staff, C&A I n f ormation Assurance personnel from 
SPAWAR San Diego and Charleston, and IA representatives from Telos Corporation and 
the Information Assurance Analysis Center were interviwed for this study. The selected 
individuals have considerable experience in the field of lA and are experienced users and 
developers of automated C&A tools. The interview for this study was conducted via 
phone and email. The questions on the interview focused on the lA posture of Navy 
Medicine C&A and information on the performance of the two automated C&A tools, 
namely, Xacta and eMASS. Afterwards, the results of the interview were collected, 
categorized and analyzed. 

In the second method, two attachments from the DoDI 8500.2, Information 
Assurance Implementation Guide were used in the policy analysis. For the purpose of this 
analysis, these two attachments represented the recommended assurance levels and 
integrity, availability and confidentiality thresholds needed in the processing, handling 
and storage of protected health information (PHI) being transmitted across Navy 
Medicine information systems. The first attachment used was the E4.A2, Attachment 2 to 
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Enclosure 4, Mission Assurance Category II (MAC II) for High Integrity and Medium 
Availability and the second attachment was E4.A5, Attachment 5 to Enclosure 4 
Confidentiality Controls for DOD Information Systems Processing Sensitive Information. 
The lA controls from the two attachments were mapped to the sections and appendices of 
the DITSCAP SSAA. The results of the mapping were tabulated and analyzed. 


B. C&A AUTOMATED TOOL ANALYSIS 

The limited information obtained describing the actual performance of the two 
C&A tools, Xacta and eMASS, were based on interviews from experienced users of the 
automated tools and review of literature from the developers of the automated tools. 

1. Xacta C&A Automated Tool Analysis 

Some of the observations that were provided by actual users of the Xacta C&A 
tool described it as a web-based tool that requires a license for each project. The tool 
requires a Structured Query Language (SQL) server on a host computer. The Xacta 
administrator creates and deletes user accounts and privileges and Xacta’s output is in 
Microsoft Word (MS Word) format. 

In actually using the Xacta C&A tool, the users described the advantages in 
utilizing the tool in completing the C&A projects. Some of the benefits identified are: 

(1) Generates significant time savings in creating templates for the SSAA and 
associated appendices. The tool assists in formatting, table creation and 
publishing. 

(2) Facilitates automatic creation of the Security Requirements Traceability 
Matrix (SRTM) and the Security Test and Evaluation (ST&E) Plan. The tool 
provides a user friendly interface for entry of ST&E results. 

(3) Provides a guided method in evaluating residual risks with an automatic 
creation of the risk assessment documentation. The tool contains many built- 
in references and predefined summaries of the DITSCAP 8510.1-M sections. 

(4) Provides a built-in vulnerability and scanning tool functionality. 

(5) Provides flexibility in allowing changes to the certain Xacta code that 
facilitates creation of additional sections to the SSAA. 

(6) Provides a customer-oriented, service based, excellent response time, technical 
and customer Xacta tool help desk support. 


However, the users of the Xacta C&A tool also described some disadvantages 
they experienced in using the tool for their C&A projects. Some of the challenges are: 
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(1) There was difficulty in tracing the ST&E cases back to the SRTM. The ST&E 
plan created by the tool did not include a summary matrix with backward 
referencing. A manual trace on hardcopy SSAA has to be done by the SSAA 
reviewers. 

(2) The presentation of results for the Detect Tool is not user friendly. The 
vulnerability information results should be improved to have a more user 
friendly format similar to the Internet Security Solutions System Scanner 
(ISS) format for ease on user familiarity. 

(3) The vulnerability information results generated by the Xacta Detect tool were 
not automatically included in the residual risk assessment determination. 
There should be a feature that allows user options to include the vulnerability 
information in the risk assessment. 

(4) The spell check feature was not available as a built in function in the Xacta 
tool. This functionality becomes accessible only after document generation in 
MS Word format. Spell checking the SSAA and appendices after publishing 
became an extra step and a time consuming task. 

(5) The Appendix A generated by the Xacta C&A tool contained numerous 
outdated acronyms. Automatic addition of new acronyms to Appendix A 
should be a built-in feature. Considerable time and effort was needed to 
manually tailor Appendix H (Security Test and Evaluation Plan and 
Procedures) to the actual SSAA. This effort resulted in the reduction of the 
total number of appendix pages from 16 to 5 pages. 


The observations noted by users of the Xacta C&A tool yielded suggested 
improvements for the IS developers. These suggested improvements include: 

(1) The automatic generation of the ST&E document should include all the tests 
that are referenced in the SRTM. Otherwise, the Xacta tool must be able to 
inform the user if there were tests in the SRTM that were not included in the 
ST&E. This is a critical feature that can affect the tool’s overall usability. 

(2) An automated trace back functionality from the ST&E to the SRTM should be 
built in together with tabular or matrix format information that allows for a 
manual trace back. The automatic trace back is a useful tool for the Xacta 
C&A tool users and the manual trace back feature is for the reviewers using 
SSAA printed copies. 

(3) The format of the Detect Tool vulnerability scan information should be 
modified to a format similar to the ISS vulnerability scan result format. This 
allows for ease of navigation and readability for the Xacta C&A tool users. 
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2. eMASS-NG C«&A Automated Tool Analysis 

The next generation eMASS C&A tool is on its final development stage and will 
be available through several pilots in the near future. However, one of the key things in 
the literature review provided by the developers of eMASS noted that the eMASS base 
code is the property of DoD. A quality that can be crucial in terms of cost benefit 
especially in software licensing. An analysis of the eMASS-NG functionalities and 
capabilities will be discussed based on the literature review obtained from the eMASS 
developers. 

Unlike Xacta which is DITSCAP based, eMASS is based on a newly written lA 
process called the DoDI 8510.bb, Defense Information Assurance Certification and 
Accreditation Process (DIACAP). The DIACAP is a new process for the C&A of all 
DoD information systems and is projected to be the future replacement to DITSCAP 
pending review and approval from DoD and all its branch services. 

At the core of eMASS is the DIACAP Knowledge Base (KB) also known as 
Knowledge Services (KS). The Knowledge Base is a web based DIACAP knowledge 
bank that provides current GIG lA C&A guidelines. It is a repository of tools, diagrams, 
process maps, artifacts to assist and facilitate in DIACAP execution. More importantly, it 
gathers members of the C&A user working group to collaborate by developing, trading 
and sharing best business lessons and practices discovered in the C&A process. The KB 
also serves as source of lA current events keeping users updated with pertinent lA 
information. 

For the purpose of lA, DIACAP classifies all DoD IS into four main categories. 
The categories are (1) enclaves, (2) AIS applications, (3) outsourced IT-based processes 
and (4) platform IT interconnections. The importance of the DIACAP process in support 
of a manual or automated C&A process is it allows (1) the users to relentlessly supervise 
lA systems to ensure conformity with key regulatory, like DoD 8500 series and 
legislative, such as FISMA policy, (2) the data from all lA systems to be electronically 
documented, (3) determines limits or boundaries and (4) lA systems achieve C&A 
conforming to policy standards. 
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A KB user can expect to find the KB as one stop shop that would facilitate the 
C&A process by assisting the user in (1) discovering the most updated GIG lA C&A 
guidelines, (2) achieving the proper control set identification in a system, (3) acquiring 
validation tests and its established results, (4) getting and sharing global advice from 
fellow lA users implementing the DIACAP process, (5) accessing useful publishing tools 
and (6) obtaining the most current reliable information on software testing tools. 

The method eMASS maps to the C&A policy is by managing the key activities in 
the DIACAP workflow and by automatically producing the C&A process workflow when 
a system is registered, personnel chosen to enforce the process functions and a system 
C&A package is produced. 

The role of the C&A proponents in eMASS are aligned to the C&A policy. Some 
of the default C&A roles in eMASS are the Designated Approving Authority (DAA), 
Certification Authority (CA), Program Manager (PM), User Representative (UR), 
Information Assurance Manager (lAM), Validation Tester and eMASS Administrator. 
The combination of role and organization determine user authority in accessing different 
components of eMASS. Personnel assigned to these roles perform critical functions in the 
C&A workflow. Additional new roles can be configured as needed. Section 6.5 of the 
DITSCAP identify and define the C&A team members responsible for the development 
of the SSAA however, the eMASS Assign Personnel feature in the C&A module assists 
the user in determining the names of the C&A team members assigned to the C&A roles. 

One of the key features of eMASS is its Controls Administration Module (CAM). 
The eMASS CAM allows its users to author and manage lA control sets, subject areas 
and controls appropriate to three layers. These layers are the DoD Enterprise, DoD 
Component, and DoD Information System. The CAM allows users to attach 
implementation guidance to lA controls as reference material while performing the C&A. 
This is very usefril especially when C&A reviewers want to do a trace back. The CAM 
also provides users with the ability to author generic validation procedures and expected 
results for lA controls. Lastly, the eMASS CAM permit users to generate controls reports 
to determine residual risk on sections that warrant remediation. The eMASS CAM is also 
responsible for the handling of lA controls MAC and Confidentiality. Through the 
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eMASS CAM suggested ways of implementing activities required to achieve the 
implementation of lA controls can be assigned and accounted. 

The eMASS C&A module authorize users to (1) view systems within eMASS 
where the user has appropriate level access, (2) enroll new systems using the IT 
registration procedure, (3) oversee and handle lA controls and their respective validation 
procedures, and (4) interface with systems as the workflow process is accomplished. 

The concept of inheritability is implemented as a time saving feature in the 
eMASS C&A module. This concept of inheritability allows the use of a system’s control 
status and applying it to another system much like a parent to a child. These parent and 
child relationship between systems can be established during the eMASS registration 
process. Users can save time by using the inheritability characteristic in the eMASS C&A 
module by applying a parent’s system’s control status and validation test results. This 
means that if a child system package inherits control status from its parent system 
package for one of its controls then the user does not have to test that control and the 
parent system’s test result would count for the child system package. This eliminates 
redundancy and saves time. 

The concept of acceptance is also implemented in the eMASS C&A module. This 
time this concept allows parent systems to accept child system tests for a control for 
independent included system only. This comes very useful only for lA controls of a 
similar grouping. However, controls must be of equal or greater stringency on the child 
system. 

The next generation eMASS C&A tool will be made available to its users without 
charge for licensing or development upgrades. eMASS also claims that it does not require 
an organizational investment in COTS software licenses and training (eMASS-NG, 
2004). The eMASS free licensing feature may prove to be beneficial in total cost of 
ownership compared to the licensing issues that affected the Xacta users. 

C. INFORMATION ASSURANCE POLICY ANALYSIS 

The information obtained in the analysis of lA policy was conducted using the 
DODI 8500.2 and the DITSCAP SSAA. The DODI 8500.2 enforces policy, designate 
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responsibilities and stipulate procedures for administering integrated, layered protection 
the DoD information systems and networks as prescribed in the DoD Directive 8500.1. 
The DODI 8500.2 ensures that information assurance levels for DoD information systems 
are assigned explicit lA controls. DODI 8500.2 is a major instruction that is strictly 
followed for compliance by all automated C&A tool vendors and developers. The SSAA 
is the cornerstone document of the DITSCAP that captures all of the lA controls for a 
system. The SSAA also discusses IA control implementation in the architecture and 
design and pretests the test procedures for testing the controls. 

With the advent of the Health Insurance Portability and Accountability Act 
(HIPAA) Final Rule on Security and Privacy, it was assumed, for the purpose of this 
analysis, that the highest possible data classification for Navy Medicine healthcare 
information was a Mission Assurance Category II (MAC II) High Integrity and Medium 
Availability level and a Sensitive Information Confidentiality Control level. Each lA 
control from the specified sections of the DODI 8500.2 was mapped to each DITSCAP 
SSAA section. The purpose of this analysis is to show that the lA controls required in 
DODI 8500.2, as applied to Navy Medicine healthcare data, have a proper place for 
discussion and consideration in the DITSCAP SSAA. 

The mapping of the DODI 8500.2 lA controls against the DITSCAP SSAA 
sections resulted in two tables. The tables showed the IA Control Number, IA Name, IA 
Service and the corresponding SSAA paragraph number(s) that map to the specific lA 
control. After completing the tables, each SSAA appendix and section number was 
verified with its mapping to an lA control. The results showed that all the SSAA sections 
mapped to the lA controls with the exception of three sections in the DITSCAP SSAA. 

This result shows that certain sections of the SSAA that did not map to an IA 
control may (1) have no purpose, (2) be used as an introduction for a more detailed 
section, (3) be extraneous, or (4) be a section with duplicate information and can be 
discarded. Sections of the SSAA that did not map to the lA controls can be removed from 
the SSAA. This can result to a more concise, shorter format of the SSAA. However, these 
sections have to be carefully examined in context. Sections of the SSAA that exist for 
readability for the C&A proponents can remain in the SSAA. 
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The three SSAA sections that did not map to any IA control are shown in Table 7. 
After careful examination of the description of each section it became obvious that these 
sections exist in the SSAA for the purpose of readability, clarity and tractability. 

The Certification and Accreditation Statements (Appendix R) did not map to any 
lA control but are in the SSAA because they are simple paragraphs where the Certifier 
attests that the system meets the design and implementation standard per regulation and 
policy, that the system complied with the defined security requirements operating the 
system and that the DAA approves of the risk to the system as designed, giving an 
approval to operate (ATO) or interim approval to operate (lATO). This appendix can be 
condensed into a single document but it is a necessary document in the SSAA. 

The Acronym List (Appendix A) did not map to any lA control but is necessary in 
the SSAA because it facilitates clarity in describing the user’s information system 
certification and accreditation documentation. Users should develop their own list of 
appropriate acronyms that are tailored for their C&A process. 

Section 2.1 of the SSAA, Operating Environment did not map to any lA control 
but is still necessary documentation in the SSAA because it provides an overview of the 
operating environment. It serves as an introductory section for readability and prepares 
the section for a detailed analysis of the Operating Environment in the subsections. The 
set of lA controls that were used for this analysis required mappings to detailed sections 
of the SSAA. That accounted for subsections of Section 2.1, (Facility Description, 
Physical Security, Administrative Issues, Personnel, COMSEC, TEMPEST, Maintenance 
Procedures, and Training Plans) to map to the lA controls and not Section 2.1, which 
provided an overview of the operating environment section of the system. 
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Table 6. Mission Assurance Category (MAC) II for High Integrity and 

Medium Availability 
E4.A2 Attachment 2 to Enclosure 4 
lA Control Mapping to DITSCAP SSAA 


lA 

Control 

Number 

lA name 

lA services 

SSAA paragraph. No. 

DCAR-1 

Procedural Review 

Availability 

4.1;4.4;4.7;Appendix L 

DCBP-1 

Best Security Practices 

Integrity 

4.4;4.5; 6.1.3; 

DCCB-2 

Control Board 

Integrity 

2.2;4.4;4.6 

DCCS-2 

Configuration Specifications 

Integrity 

4.4;4.5; Appendix M; 

Appendix C 

DCCT-1 

Compliance Testing 

Availability 

Appendix G; Appendix H 

DCDS-1 

Dedicated lA Services 

Integrity 

1.3.2; 2.1.4; 2.1.5; 2.1.7;4.3; 
5.4; Appendix Q; Appendix F 

DCFA-1 

Functional Architecture for AIS 
applications 

Integrity 

1.1; 1.2; 1.3.4; 2.1.4; 2.1.5; 
3.1;3.2;3.3;4.3; Appendix L, 
Appendix M 

DCHW-1 

Hardware Baseline 

Availability 

3.1; 

DClD-1 

Interconnection Documentation 

Integrity 

1.1; 3.2; 4.5; Appendix N 

DCII-1 

lA Impact Assessment 

Integrity 

4.7; 

DCIT-1 

lA for IT Services 

Integrity 

2.1.4; 2.1.5; 2.1.6; 2.1.7; 4.3; 

DCMC-1 

Mobile Code 

Integrity 

4.1; 4.2; 4.4; 6.1.1; Appendix 

Q; 

DCNR-1 

N on-Repudiation 

Integrity 

2.1.5; 4.4 

DCPA-1 

Partitioning the Application 

Integrity 

3.1; 4.4; 

DCPB-1 

lA Program and Budget 

Availability 

5.2; 6.2; 6.3; 6.4 

DCPD-1 

Public Domain Software Controls 

Availability 

2.2; 3.1; 3.2; 4.4; Appendix Q 

DCPP-1 

Ports, Protocols, and Services 

Availability 

1.3.1; 2.1.5; 3.1; 3.2; 3.3 

DCPR-1 

CM Process 

Integrity 

4.6; 4.7; Appendix G; 

Appendix H 

DCSD-1 

lA Documentation 

Availability 

1.3.4; 5.1; 5.3; 6.2; 6.3; 6.5; 
Appendix C; Appendix E; 

DCSE-1 

System Library Management 
Controls 

Integrity 

2.2; 3.1; 3.3; 4.4 

DCSP-1 

Security Support Structure 
Partitioning 

Integrity 

3.1; 3.2; 4.4; 

DCSQ-1 

Software Quality 

Integrity 

1.3.5; 2.2; 3.1; Appendix H; 
Appendix B; Appendix P 

DCSS-2 

System State Changes 

Integrity 

1.3.1; 2.1.7; Appendix H, P 

DCSW-1 

SW Baseline 

Availability 

2.1.7;3.1; Appendix L 

IAKM-2 

Key Management 

Integrity 

2.1.5; 
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IATS-2 

Token and Certificate Standards 

Integrity 

2.1.5; 

ECAT-2 

Audit Trail, Monitoring, Analysis 
and Reporting 

Integrity 

1.3.1; 2.1.3; 2.1.7; 3.1; 
Appendix J 

ECCD-2 

Changes to Data 

Integrity 

1.3.3; 1.3.4; 2.1.3; 4.7; 
Appendix M 

ECDC-1 

Data Change Controls 

Integrity 

2.1.3; Appendix J 

ECID-1 

Host Based IDS 

Integrity 

1.4; 2.1.5; 3.1; 3.2; 3.4 

ECIM-1 

Instant Messaging 

Integrity 

2.1.5; 3.2; 4.4; 4.5; 

ECND-2 

Network Device Controls 

Integrity 

2.1.3; 2.1.7; 2.2; 3.2; 

Appendix J 

ECPA-1 

Privileged Account Control 

Integrity 

1.3.4; 2.1.4; 6.1.2 

ECPC-2 

Production Code Change Controls 

Integrity 

1.3.4; 2.1.3; 2.1.4; Appendix J 

ECRG-1 

Audit Reduction and Report 
Generation 

Integrity 

1.3.1; 2.1.3; 2.1.7; 3.1; 
Appendix J 

ECSC-1 

Security Configuration 

Compliance 

Availability 

4.1; 4.2 

ECSD-2 

Software Development Change 
Controls 

Integrity 

1.3.4; 2.2; 

ECTB-1 

Audit Trail Backup 

Integrity 

1.3.1; 2.1.3; 2.1.7; 3.1; 
Appendix J, Appendix M 

ECTM-2 

Transmission Integrity Controls 

Integrity 

2.1.5; 2.1.6; 3.2; 3.3; 4.5; 
Appendix M 

ECTP-1 

Audit Trail Protection 

Integrity 

2.1.3; 2.1.7; Appendix J 

ECVI-1 

Voice over IP 

Availability 

2.1.5; 3.2; 4.5 

ECVP-1 

Virus Protection 

Availability 

2.1.7; 3.2; 4.4; 6.1.4 

Appendix J; Appendix M; 
Appendix Q; 

ECWN-1 

Wireless Computing and 
Networking 

Availability 

2.1.5; 3.2; 4.4; 4.5; 

Appendix C 

EBCR-1 

Connection Rules 

Availability 

2.1.5; 3.2; 4.1; 4.2; 4.5 

EBVC-1 

VPN Controls 

Availability 

1.4; 2.1.5; 3.1; 3.2; 3.4 

PEEL-2 

Emergency Lighting 

Availability 

2.L1;2.3;4.4; 

Appendix K 

PEFD-2 

Fire Detection 

Availability 

2.1.1; 2.1.2; 2.3; 4.4; 

Appendix K 

PEFI-1 

Fire Inspection 

Availability 

2.1.1; 2.1.2; 2.3; 4.4; 

Appendix L 

PEFS-2 

Fire Suppression System 

Availability 

2.1.1; 2.1.2; 2.3; 4.4; 

Appendix K 

PEHC-2 

Humidity Controls 

Availability 

2.1.1; 4.4; 2.3; 

Appendix K 

PEMS-1 

Master Power Switch 

Availability 

2.1.2; 4.4; 

Appendix K 
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PESL-1 

Screen Lock 

Integrity 

2.1.2; 4.4; 

Appendix K 

PETC-2 

Temperature Controls 

Availability 

2.1.2; 4.4; 2.3; 

Appendix K 

PETN-1 

Environmental Control Training 

Availability 

2.1.2; 2.1.4; 2.1.8; 4.4; 
Appendix M; Appendix 0 

PEVR-1 

Voltage Regulators 

Availability 

2.1.2; 4.4; 

PRRB-1 

Security Rules of Behavior or 
Acceptable Use Policy 

Availability 

2.1.3; 2.1.4; Appendix J 

COAS-2 

Alternate Site Designation 

Availability 

2.1.1; Appendix E, J 

COBR-1 

Protection of Backup and 
Restoration Assets 

Availability 

1.3.1; 2.1.3; 2.1.7; 3.1; 4.3; 
Appendix J, M 

CODB-2 

Data Back-up Procedures 

Availability 

1.3.1; 2.1.3; 2.1.7; 3.1; 4.3; 
Appendix J, M 

CODP-2 

Disaster and Recovery Planning 

Availability 

2.1.7; Appendix D; K; L; 

COEB-1 

Enclave Boundary Defense 

Availability 

2.1.1; 3.4; 4.4; Appendix L 

COED-1 

Scheduled Exercises and Drills 

Availability 

1.3.4; 2.1.4; 2.1.8; Appendix 
K,L 

COEF-2 

Identification of Essential 

Functions 

Availability 

1.3.4; 2.1.3; 2.1.7; Appendix J 

COMS-2 

Maintenance Support 

Availability 

2.1.7; 4.4; 

Appendix E 

COPS-2 

Power Supply 

Availability 

2.1.7; 4.4; 

Appendix E 

COSP-1 

Spares and Parts 

Availability 

2.1.7; 4.4; 

Appendix E 

COSW-1 

Backup Copies of Critical SW 

Availability 

1.3.1; 2.1.3; 2.1.7; 3.1; 
Appendix J, Appendix M 

COTR-1 

Trusted Recovery 

Availability 

2.1.3; 2.1.7; 4.4 Appendix E; 
Appendix H; Appendix J; 
Appendix L 

VlIR-1 

Incident Response Planning 

Availability 

2.1.8; 5.4; Appendix K; 
Appendix 0 

VlVM-1 

Vulnerability Management 

Availability 

2.1.8; 4.4; 4.6; Appendix E; 
Appendix 0 
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Table 7. Confidentiality Controls for DOD Information Systems Processing 

Sensitive Information 
E4.A5 Attachment 5 to Enclosure 4 
lA Control Mapping to DITSCAP SSAA 


lA 

Control 

Number 

lA name 

lA services 

SSAA paragraph. 
No. 

DCAS-1 

Acquisition Standards 

Confidentiality 

1.3.1; 1.3.2; 1.3.5; 

3.1; 3.2; 4.4; 6.1.1; 
6.1.4; Appendix D, 
Appendix E, 

Appendix I 

DCSR-2 

Specified Robustness - Medium 

Confidentiality 

1.3.1; 1.3.2; 3.1; 3.2; 
4.3; 4.4; Appendix D, 
Appendix E 

IAGA-1 

Group Identification and Authentication 

Confidentiality 

1.3.4; 2.1.5; 6.5; 
Appendix M 

IAIA-1 

Individual Identification and 
Authentication 

Confidentiality 

1.3.1; 1.3.4; 2.1.2; 
2.1.7; 6.1.3; 

Appendix H 

ECAD-1 

Affiliation Display 

Confidentiality 

1.3.1; 1.3.4; 4.4; 
Appendix E, 

Appendix H 

ECAN-1 

Access for Need-to-Know 

Confidentiality 

1.3; 1.3.3; 1.3.4; 

2.1.3; 3.3; 4.4; 4.5; 
Appendix J 

ECAR-2 

Audit Record Content 

Confidentiality 

2.1.3; 4.4; 4.5; 6.1.2 

ECAT-1 

Audit Trail, Monitoring, Analysis and 
Reporting 

Integrity 

2.1.3; 4.4; 4.5; 4.7; 
Appendix B; 

Appendix C; 

Appendix F; 

Appendix Q 

ECCR-1 

Encryption for Confidentiality (Data at 
Rest) 

Confidentiality 

2.1.5; 4.3; 

ECCT-1 

Encryption for Confidentiality (Data in 
Transit) 

Confidentiality 

2.1.5; 3.2; 3.3; 4.3; 

4.5; 6.1.3; 

ECIC-1 

Interconnections among DoD Systems 
and Enclaves 

Confidentiality 

3.2; 4.5; Appendix N 

ECLO-1 

Logon 

Confidentiality 

1.3.4; 2.1.4; 2.1.7; 

2.2; 4.5; 

ECLP-1 

Least Privilege 

Confidentiality 

1.3.4; 2.1.4; 2.2; 4.5; 
6.1.2 
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ECML-1 

Marking and Labeling 

Confidentiality 

1.3.3; 3.1; 3.2; 4.3; 

ECMT-1 

Conformance Monitoring and Testing 

Confidentiality 

2.3; 4.6; 6.2; 6.3; 
Appendix G; 

Appendix H, 

Appendix P; 

Appendix Q 

ECNK-1 

Encryption for Need-To-Know 

Confidentiality 

1.2; 1.3.3; 1.3.4; 3.3; 
4.3; 

ECRC-1 

Resource Control 

Confidentiality 

1.3.1; 2.1.7; 2.3 

ECRR-1 

Audit Record Retention 

Integrity 

2.1.3; 4.4; 4.5; 
Appendix Q 

ECTC-1 

Tempest Controls 

Confidentiality 

2.1.6; Appendix M 

ECWM- 

1 

Warning Message 

Confidentiality 

1.1;2.1.3;3.1;4.1; 

4.2; 4.4; Appendix C; 
Appendix J, 

Appendix M 

IAAC-1 

Account Control 

Confidentiality 

1.3.4;2.1.3;4.4; 
Appendix M 

EBBD-2 

Boundary Defense 

Confidentiality 

1.2; 3.1; 3.2; 3.4; 4.2; 
4.5; 

EBPW-1 

Public WAN Connection 

Confidentiality 

3.1; 3.2; 4.2; 4.5; 
Appendix N 

EBRP-1 

Remote Access for Privileged Functions 

Confidentiality 

1.4; 1.3.4; 2.1.3; 3.1; 
3.2; 4.5; Appendix E, 
Appendix F; 

Appendix J 

EBRU-1 

Remote Access for User Functions 

Confidentiality 

1.4; 1.3.4; 2.1.5; 3.1; 
3.2; 4.5; Appendix E, 
Appendix J 

PECF-1 

Access to Computing Facilities 

Confidentiality 

2.1.2; 2.1.5; 2.1.7; 

4.4; Appendix E, 
Appendix M 

PECS-1 

Clearing and Sanitizing 

Confidentiality 

3.1; 4.3; 

PEDI-1 

Data Interception 

Confidentiality 

1.3.3; 1.3.4; 2.1.2; 

3.1; 4.3; 

PEPF-1 

Physical Protection of Facilities 

Confidentiality 

2.1.2; 2.1.5; 2.1.7; 

4.4; Appendix E, 
Appendix M 

PEPS-1 

Physical Security Testing 

Confidentiality 

2.1.1; 2.1.2; 2.1.3; 
2.1.7; Appendix J, 
Appendix H 

PESP-1 

Workplace Security Procedures 

Confidentiality 

2.1.1; 2.1.2; 2.1.4; 
Appendix E, 

Appendix M 
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PESS-1 

Storage 

Confidentiality 

2.1.1; 4.3; Appendix 

E, Appendix M 

PEVC-1 

Visitor Control to Computing Facilities 

Confidentiality 

2.1.2; 2.1.3; 2.1.4; 
Appendix E, 

Appendix M 

PRAS-1 

Access to Information 

Confidentiality 

2.1.2; 2.1.4; 2.1.7; 

2.2; Appendix E, 
Appendix M 

PRMP-1 

Maintenance Personnel 

Confidentiality 

2.1.4; 2.1.7; 4.4; 
Appendix M 

PRNK-1 

Access to Need-to-Know Information 

Confidentiality 

1.3.4; 2.1.4; 3.3; 4.4; 
5.2; Appendix E, 
Appendix M 

PRTN-1 

Information Assurance Training 

Confidentiality 

2.1.8; 4.4; 5.1; 5.3; 

5.4; 6.5; Appendix E; 
Appendix K; 

Appendix L; 

Appendix 0 


Table 8. Mapping Analysis of lA Controls to SSAA 
For MAC II High Integrity and Medium Availability and 
Confidentiality Controls for DoD Processing Sensitive Information 


SSAA 

Section 

Section Name and 
Description 

Comments 

Appendix R 

Certification and 

Accreditation Statements 
Purpose: This appendix 
contains the formal 
authorization statements 
issued by the CA and DAA 
for the system to operate and 
supporting accreditation 
documentation. 

Provide copies of: 

• Requests for DAA 

Approval from the Program 
Office 

• Endorsement Letters from 
the Certification Authority 

• DAA Letters of 

Approval/Accreditation 

- Approval to Proceed 

- Interim Approval to 

These C&A Statements provide readability and 
proof that the DAA approves of the risk to the 
system as designed, giving an approval to 
operate (ATO) or interim approval to operate 
(lATO). 
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Operate 

- Approval to Operate. 


Appendix A 

Acronym List 

This is used as reference document for clarity. 

Section 2.1 

OPERATING 

ENVIRONMENT 

Purpose: This paragraph 
details the physical 
environment in which the 
system will operate, 
including the description of 
the facilities, physical 
security, administrative 
issues and personnel 
security. 

Contents 

Provide a generic description 
of the requirements for the 
physical environment in 
which the system will 
operate, including: 

• The facility 

• Physical and administrative 
security features 

• Maintenance procedures 

Serves as an introductory section. The 
Subsections of Section 2.1 were specifically 
referenced more due to the detailed nature of 
the lA controls for MAC II High Integrity and 
Medium Availability and the Sensitive 
Confidentiality of the processed information as 
stated in DODI 8500.2. This section provides 
readability to the SSAA. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. INTRODUCTION 

The C&A process within the DoD, MHS and Navy Medicine is achieved in 
accordance with DoDI 5200.40, “DoD Information Technology Security Certification 
and Accreditation Process (DITSCAP).” It enforces the lA policies described in DoDD 
8500.1, “Information Assurance (lA) and DoDI 8500.2, “Information Assurance (lA) 
Implementation”. The DITSCAP applies to all the elements of the DoD, their contractors 
and agents. Furthermore, it is adopted by milestone decision authorities when acquiring 
IT resources and for the acquisition, administration and sustainment of any DoD system 
that is in the business of collection, storage, transmission or handling of unclassified, 
sensitive but unclassified or classified information. 

The MHS lA Policy/Guidance and the BUMED AIS Security Program Policy is 
the governing policy for all Navy Medicine C&A initiatives. Policy is a major vector of 
lA vulnerabilities in large and complex organizations. Automated C&A tools that have a 
formal policy analysis methodology based on knowledge management tools, particularly 
object oriented databases, can greatly reduce policy-based vulnerabilities. Automated 
C&A tools like Xacta and eMASS have to comply with major federal, DoD and civilian 
lA and C&A policies. These tools must have enough flexibility to accommodate future 
policies and policy changes. Automated tools, if designed properly, have the potential to 
provide standardized C&A security across sites and systems with web based workflow 
and configuration management. These automated C&A solutions can (1) reduce required 
resources, (2) improve C&A process turn around time (3) ensure consistent standards, (4) 
provide accurate and comprehensive management reporting for the enterprise, (5) be 
scaleable. These tools can greatly enhance the information needed by a DAA in making a 
sound and well founded decision in either accepting or rejecting the residual risk 
assessment to allow an ATO or lATO. 
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B. THESIS QUESTIONS REVIEW 

1. Are existing Navy Medicine C&A policies in alignment with current DoD, 
Navy Policy and federal government requirements? The existing Navy Medicine C&A 
policy is accomplished in accordance to the BUMED AIS Security Program Policy 
Manual and the MHS lA Security Policy/Guidance Manual version 1.3. The BUMED 
and MHS lA Security manuals strictly conform to the DoDl 5200.40, DoDD 8500.1 and 
DoDI 8500.2. However, Navy Medicine C&A policies would need to be updated to 
reflect relevant changes in the current policy that may be a result of the use of automated 
C&A tools in the C&A process. 

2. Would the use of automated C&A software technology benefit the Navy 
Medicine C&A process? The use of automated C&A software technology would benefit 
Navy Medicine C&A process. This is true provided that Navy Medicine C&A team 
invest time and resources in evaluating the right tool that would fit the Navy Medicine 
C&A process. The Navy Medicine C&A process follow the DITSCAP. Navy Medicine 
commands and activities still use the manual method of C&A. Information gathering 
entails manual entry of hardware and software information. The management of security 
regulations are done by manually highlighting applicable regulations in hard copy or 
softcopy of IA security manuals. Testing is accomplished by manual development of 
checklists and test procedures. Document formatting is produced by using multiple word 
processing applications, managing fonts, tabs, formats and the like. The use of automated 
C&A tools like Xacta and eMASS can greatly improve the quality and turn around time 
of the C&A reporting and documentation in the Navy Medicine C&A process. 

3. Would the use of automated certification and accreditation tools be a cost 

effective means to address Navy Medicine C&A lA threats and vulnerabilities? Historical 

data showed that Navy Medicine has approximately 15,000 health and patient care 

related systems including legacy systems. It approximately costs Navy Medicine around 

$2M per year in maintenance costs to protect its information assets using manual 

scanning and patch management alone as part of compliance to the Navy Medicine C&A 

and HIPAA requirements. The Xacta Group estimates that for a Level 3 C&A or 

equivalent (DITSCAP, NIACAP, NIST, DCID), a local area network with 250 devices 

consisting of 50 servers, routers and switches, including 200 workstations and printers 
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with platforms ranging from Windows, HPUX, Linux and Solaris, at $80.00 per hour the 
total cost of a C&A project for a system using the manual C&A method would cost an 
estimated $180,480 using an estimated 2,256 man hours. But by using the Xacta C&A 
tool with its automated C&A features, the C&A process of a similar system would be 
completed with an estimated reduced cost of $52,640 using 658 man hours. The 
organization can have considerable savings using automated C&A tools in their C&A 
process. 

The functionalities of automated C&A tools can greatly improve the manual Navy 
Medicine C&A process by its (1) automatic discovery, inventory, scanning and loading 
of C&A information in its central database, (2) automatic generation of the SRTM , (3) 
automatic generation of content management documentation, (4) automatic mapping to 
test procedures to determine pass or fail conditions, and (5) automatic publishing 
capabilities for the SSAA and its appendices. 

The use of automated C&A tools would not replace the Navy Medicine C&A 
staff but it would allow them valuable time to address other significant lA and C&A 
issues. The automated C&A software technology would prove beneficial especially if 
Navy Medicine has the means of acquiring them like the Xacta C&A tool. In addition, 
eMASS can prove to be very beneficial automated C&A solution for Navy Medicine 
especially because it is owned by DoD and will be made available without charge for 
licensing or development upgrades. 

4. Would a consolidated and centrally-managed knowledgebase of C&A 
policies improve Navy Medicine’s current security posture? 

The automated C&A tools, Xacta and eMASS, were designed with the core of 
their content management functionality stored in centrally managed databases. The 
Xacta lA Manager Enterprise edition has an internal relational knowledge base and 
database that stores over 100 leading federal, DoD, and civilian regulations and policies 
for IT risk compliance and management. The eMASS-NG also has an integrated 
knowledge base resource that provides current Global Information Grid (GIG) C&A 
federal, DoD and civilian guidelines. It has a library of tools, diagrams, process maps, 
artifacts to support and aid in the execution of the C&A process. 
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These centrally managed knowledge base resources that are built in the automated 
C&A tools can revolutionize the Navy Medicine C&A process in effectively meeting 
their C&A objectives, proactively managing its lA program, and have real time decision 
support capabilities using one-time data entry to assist the DAA in making a sound 
decision of accepting or rejecting the residual risk assessment to approve, interim 
approve or reject system operation. 

C. RECOMMENDATIONS FOR IMPROVING NAVAL MEDICINE 
CERTIFICATION AND ACCREDITATION PROCESS 

This study looked into the role of automated C&A tools in the Navy Medicine 
C&A process by examining the capabilities of Xacta lA Manager and eMASS. It also 
looked into DoDI 8500.2 as a major DoD lA instruction as its lA controls are mapped to 
the DITSCAP SSAA. 

In order for the Navy Medicine C&A process to fully benefit from using 
automated C&A tools, it has to examine if the automated C&A tool’s functionalities fit 
their needs, match their resources and capabilities and add value to their C&A process. 
The mission of these C&A tools is to assist the C&A main proponents in establishing a 
C&A process that reduces required resources, ensures consistent standards, provides 
management reporting to the enterprise and is scaleable. 

Given that the automated tools produce documentation that assists the DAA 
understand the residual risk, these tools should produce concise yet comprehensive and 
understandable reports to guide the DAA in making his decision. The Xacta lA Manager 
DITSCAP based tool produces the SSAA that provides the DAA with a complete report 
on the technical and non-technical information with test procedures to support the 
residual risk assessment. The SSAA which is a living document that (1) contains agreed 
items by the C&A main proponents and (2) identifies all costs relevant to the C&A 
process, is perceived to be a very tedious and time consuming document to complete. 

On the other hand, eMASS, whose reporting format is still in development, is 
designing a more concise yet comprehensive score card which would assist the DAA in 
evaluating the residual risk assessment. eMASS is based on the Defense Information 

Assurance Certification and Accreditation Process (DIACAP) DoDI 8510.bb which is 
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projected to replace the DITSCAP once it passes evaluation by DoD and other federal 
agencies. Some suggested items that a DAA would like to see in the eMASS scorecard 
would be a report that shows evidence of the risk such as a concise residual risk scorecard 
that documents the technical risks discovered in the C&A process with the associated 
management impacts with cost values in a prioritized list. 

The Navy Medicine C&A team should closely scrutinize the internal and external 
capabilities of the automated C&A tools Xacta and eMASS. They need to consider how 
these tools can significantly contribute to the C&A process with its time-saving and value 
added features. Based on the analysis conducted on the two automated tools, below is a 
checklist containing suggested fact finding questions that would be the criteria in 
assisting Navy Medicine in evaluating the acquisition of an automated C&A tool. 


Table 9. Criteria for selecting an appropriate automated C&A tool 


Criteria 

Yes 

No 

Does the automated C&A tool have a built in feature to handle lA 
control implementation and testing? 

Does the tool allow users to obtain suggested ways to implement and 
test lA controls or do the automated tools only produce an outline of 
technical information to assist the user in testing and implementing lA 
controls? 



Does the automated C&A tool create a collaborative workspace 
environment for its user community in order to develop, share and 
post lessons learned with best corrective actions? 

Does it provide a forum to hear about user real-world experiences 
implementing their chosen C&A policies? 



Does the tool automatically figure out what lA control sets are needed 
in a given system? 

Automatically find validation tests with expected test results? 



Is the tool web based? Is it publisher friendly? 

Does it allow easy access to useful forms and templates? 

Does it accept all standard characters? 

Does it allow the easy addition of extra sections in the report by 
modifying source code? 

Does it allow collaboration among multiple users or multiple roles? 



Does the tool interface with third party software testing tool like the 
Defense Information Systems Agency (DISA) Gold Disk? 

Does the tool generate test scripts for testing requirements? 

Does the tool have a built in vulnerability scanner? 
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Does the tool have a steep or manageable learning curve? 

Is there 24/7 online or phone technical support for the users? 



Does the tool track the progress of lA activities? 

Does the tool track current C&A status of systems? 

Does the tool provide visibility into current lA system security status? 



Is the automated C&A tool cross compatible with different lA 
policies? 

Does it leave room for growth to accommodate new and revised 
policies? 



Does the tool’s built in report generation feature allow customization 
of reports according to the role of the C&A proponent requesting the 
report? 

Does the automated C&A tool produce a report specific for the DAA, 
CA, PM, UR, lAM to assist them in their decision making or 
recommendation of an ATO or lATO of a system? 



Is the enterprise license for the tool free or proprietary? 

How much organizational investment in hardware, licenses and 
training is needed? 




D. SUMMARY 

In summary, the analysis conducted in this research showed clear evidence that 
both automated C&A tools support the C&A process. The analysis of the automated 
C&A tools showed that the tools supported the proposed C&A process by mapping the 
confidentiality, integrity and availability assurance requirements following the 
DITSCAP. By taking the confidentiality, integrity and availability requirements of a 
typical naval healthcare system and mapping it to the DITSCAP, the analysis assured that 
the information assurance controls are confirmed in the information system or the 
network. Furthermore it assures the users that the cornerstone of the DITSCAP is 
definitively documented in the SSAA. The Xacta automated C&A tool using the 
DITSCAP showed that the C&A process was supported. The eMASS automated C&A 
tool provides suggested ways to incorporate the C&A documentation but does not 
directly do it for the users. 

The benefit that can be derived from the utilization of automated C&A tools in the 
Navy Medicine C&A process can only promote a healthier, robust and more secure 
networking environment for Navy Medicine professionals while significantly decreasing 
residual risk. The constant increase of threats and vulnerabilities to systems in 
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conjunction with increased dependability on networked information systems, develop an 
overwhelming demand to maintain confidentiality, integrity and availability of 
information assets. The reduction of demand for resources required to conduct a C&A of 
a system using automated C&A tool will produce an immediate return on investment to 
Navy Medicine if funding allows for it. In purchasing an automated C&A tool, a good 
understanding of the C&A tool’s expected functionality and features by the C&A team 
would prevent acquiring the wrong C&A tool resulting in wasted effort, money and man 
hours. Otherwise, the Navy Medicine C&A team should consider making plans to obtain 
and evaluate free govemment-off-the-shelf (GOTS) automated C&A tool to improve 
their C&A process. 

Information assurance experts all over the world agree that today’s networked 
domains are susceptible to more risk than before. Federal agencies, DoD components and 
civilian organizations that do not take advantage of the benefits of an automated C&A 
solution in combination with layered defenses expose themselves and their clients to an 
increased risk compared to those organizations that are continuously improving their lA 
security posture by being more proactive and assertive in securing their information 
system resources. By using an automated tool, an organization will facilitate capturing a 
detailed explanation of the implementation of the lA controls and development through 
test cases to confirm them. This will illustrate areas for risk management and more 
accurately represent the residual risk to the DAA for acceptance. 
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APPENDIX B. MESSAGE FROM CNO N64 DTG: 191943Z JUN 00 
CERTIFICATION AND ACCREDITATION OF SYSTEMS AND 
NETWORKS 


UNCLASSIFIED 
ACTION: BUMED 

COG: OLA/ASN FM/ASN MRA/ASN lE/UNSECNAV/DON CIO 

R091943Z JUNOO 

FM:CNO WASHINGTON DC//N64// 

INFO UNSECNAV WASHINGTON DC//AAUSN// 

ASSTSECNAV FM WASHINGTON DC 
ASSTSECNAV IE WASHINGTON DC 
ASSTSECNAV MRA WASHINGTON DC 

CNO WASHINGTON DC//NI/N2/N3/N4/N4T/N43/N5/N6/N7/N8/N82/ 

N83/N09/ 

N09B/N095/N096/N097// 

OLA WASHINGTON DC 

Subject:CERTIFICATION AND ACCREDITATION OF SYSTEMS AND 
NETWORKS// 

UNCLAS //N05239// SECTION 01 OF 02 
MSGID/GENADMIN/CNO N64// 

SUBJ/CERTIFICATION AND ACCREDITATION OF SYSTEMS AND 
NETWORKS// 

REF/A/DOC/DOD/21MAR8 8// 

REF/B/DOC/DOD/IOFEB98// 

REF/C/DOC/CNO/09NOV99// 

REF/D/DOC/CNO/MAYOO// 

REF/E/DOC/CNO/MAYOO// 

NARR/REF A IS DOD DIRECTIVE 5200.28 - SECURITY REQUIREMENTS FOR 
AUTOMATED 

INFORMATION SYSTEMS (AIS'S). 

REF B IS DOD INSTRUCTION 5200.40 - DOD INFORMATION SYSTEM 
TECHNOLOGY SECURITY CERTIFICATION AND ACCREDITATION 
PROCESS (DITSCAP). 

REF C IS OPNAVINST 5239.IB - NAVY INFORMATION ASSURANCE 
PROGRAM. 

REF D IS DON lA PUB MODULE 5239-01 - INTRODUCTION TO INFORMATION 
ASSURANCE (lA) GUIDEBOOK. 

REF E IS DON lA PUB MODULE 5239-13 - INFORMATION ASSURANCE 
CERTIFICATION PAGE 06 RUENAAA4545 UNCLAS AND 
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ACCREDITATION (C&A) PUBLICATION, VOLUMES I - III (DRAFT VOLS I & II 
ARE POSTED ON THE INFOSEC WEB SITE. 

DRAFT VOL III WILL BE POSTED WHEN AVAILABLE).// 

POC/MS. LOUISE DAVIDSON/GS-15/N643/CNO/TEL:703-601-1261/DSN:329- 
I26I/EMAIL:DAVIDSON.LOUISE(AT)HQ.NAVY.MIL// 

POC/MR. DAVID CROTTY/PMW-16I/SPAWAR/TEL:TBD/619-524-734I/DSN:524- 
734I/EMAIL:CROTTYD(AT)SPAWAR.NAVY.MIL.// 

RMKS/1. BACKGROUND. DOD POLICY (REFS A AND B) MANDATES THAT 
ALL AUTOMATED INFORMATION SYSTEMS (AIS'S), 

NETWORKS AND SITES BE CERTIFIED AND ACCREDITED IN ACCORDANCE 
WITH THE DITSCAP. RECENT NAVY EFFORTS 

TO ENFORCE THE NAVY'S FLEET FIREWALL POLICY AND TO COMPLY WITH 
THE DISN(SIPRNET AND NIPRNET) 

CONNECTION APPROVAL PROCESS (CAP) HAVE IDENTIFIED SEVERAL 
LEGACY AND NEW, NAVY PROGRAM OF RECORD (POR) 

DEPLOYABLE AND JOINT/DOD SYSTEMS THAT ARE NOT IN COMPLIANCE 
WITH THIS POLICY. 

2. POLICY AND GUIDANCE. REFS C THRU E PROVIDE SPECIFIC NAVY 
POLICY AND GUIDANCE IMPLEMENTING REFS A AND B. 

IN SUMMARY: 

A. ALL DOD SYSTEMS THAT COLLECT, STORE, TRANSMIT OR PROCESS 
UNCLASSIFIED OR CLASSIFIED INFORMATION 

THAT IS ACQUIRED, OPERATED OR SUSTAINED SHALL BE CERTIFIED AND 
ACCREDITED. THIS INCLUDES 

THE PAGE 07RUENAAA4545 UNCLAS DEVELOPMENT OF NEW AIS, THE 
INCORPORATION OF AIS INTO THEEXISTING 

INFRASTRUCTURE, PROTOTYPES, RECONFIGURATIONS OR UPGRADES TO 
EXISTING SYSTEMS AND LEGACY SYSTEMS. 

(1) DESIGNATED APPROVING AUTHORITY (DAA) RESPONSIBILITY FOR 
NAVY SYSTEMS - A DAA SHALL 

BE ASSIGNED FOR EVERY SYSTEM lAW REF C. 

(2) SYSTEM SECURITY AUTHORIZATION AGREEMENT (SSAA): 

* FOR NAVY INSTALLED FLEET AND LOCALLY ACQUIRED SYSTEMS, PRIOR 
TO MAKING AN 

ACCREDITATION DECISION, DAA'S SHALL ENSURE THAT THE SYSTEMS 
COMPLY WITH THE MINIMUM 
DIRECTION PROVIDED lAW REF E. 
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* FOR NAVY POR/DEPLOYABLE SYSTEMS, PRIOR TO MAKING AN 
ACCREDITATION DECISION, DAAS 

SHALL ENSURE THAT THE NAVYS CERTIFICATION AUTHORITY (CA - 
SPAWAR PMW-161) HAS FORMALLY 

REVIEWED THE MOST RECENT VERSION OF THE SSAA(GENERATED lAW 
REF E). UPON REVIEW OF THE SSAA, 

THE NAVYS CA SHALL ISSUE A STATEMENT ASSESSING THE 
QUALITY/ADEQUACY OF THE DOCUMENTED 

CERTIFICATION PROCESS AND SPECIFIED SECURITY SOLUTIONS AS WELL 
AS, WHERE APPROPRIATE, 

RECOMMENDATIONS FOR IMPROVING THE SYSTEMS SECURITY POSTURE. 

* FOR JOINT/DOD SYSTEMS, THE NAVYS CA SHALL FORMALLY REVIEW 
THE MOST RECENT VERSION OF 

THE SSAA (GENERATED lAW REF B) PRIOR TO INSTALLATION OF ANY NEW 
SYSTEM OR UPGRADE TO 

AN EXISTING SYSTEM AT PAGE 08 RUENAAA4545 UNCLAS ANY NAVY SITE. 
UPON REVIEW OF THE SSAA, 

THE NAVYS CA SHALL ISSUE A STATEMENT ASSESSING THE 
QUALITY/ADEQUACY OF THE DOCUMENTED 

CERTIFICATION PROCESS AND SPECIFIED SECURITY SOLUTIONS AS WELL 
AS, WHERE APPROPRIATE, 

RECOMMENDATIONS FOR IMPROVING THE SYSTEMS SECURITY POSTURE. 

* AIS PROCESSING AT MULTIPLE LEVELS OF SECURITY (MLS), BRIDGING 
MULTIPLE SECURITY LEVELS 

(MSL - INCLUDING US-ONLY TO FOREIGN/ALLIED/COALITION CLASSIFIED 
CONNECTIONS), PERFORMING 

COMMUNICATIONS SECURITY(COMSEC), AND/OR SPECIFICALLY DESIGNED 
TO PROVIDE INFORMATION 

SYSTEM SECURITY (INFOSEC), SHALL MEET ADDITIONAL CERTIFICATION 
REQUIREMENTS AS MANDATED 

BY THE SECRET AND BELOW INTEROPERABILITY (SABI) INITIATIVE, 
NATIONAL SECURITY AGENCY (NSA), 

DEFENSE INTELLIGENCE AGENCY (DIA), NATIONAL INSTITUTE OF 
STANDARDS AND TECHNOLOGY (NIST), 

AND/OR NATIONAL SECURITY TELECOMMUNICATIONS AND 
INFORMATION SYSTEMS SECURITY COMMITTEE (NSTISSC). 

CNO N643 OR SPAWAR PMW-161 SHOULD BE CONTACTED FOR SPECIFIC 
DETAILS. 


(3) PRIOR TO INSTALLATION OF ANY NEW POR/DEPLOYABLE SYSTEM, OR 
UPGRADE/RECONFIGURATION TO 

AN EXISTING LEGACY SYSTEM, THE SYSTEM DAA SHALL PROVIDE A 
FORMAL TYPE ACCREDITATION 
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DECISION (EITHER INTERIM OR FINAL TYPE APPROVAL TO OPERATE 
(lATO/ATO) AND A COPY OF THE 

SYSTEMS PAGE 09 RUENAAA4545 UNCLAS SSAA TO THE SITE/LOCAL DAA 
FOR LOCAL IMPLEMENTATION 
AND ACCREDITATION. 


(4) EXISTING LEGACY SYSTEMS MUST MAINTAIN A CURRENT 
ACCREDITATION STATUS THROUGHOUT THE 

ENTIRE LIFECYCLE OF THE SYSTEM. PROGRAM MANAGERS FOR EXISTING 
LEGACY SYSTEMS THAT HAVE 

NOT BEEN CERTIFIED AND ACCREDITED IN ACCORDANCE WITH THE 
DITSCAP, OR WHOS DITSCAP BASED 

CERTIFICATION AND ACCREDITATION HAS EXPIRED, SHALL 
EXPEDITIOUSLY TAKE PROACTIVE MEASURES 
TO (RE-)CERTIFY AND (RE-)ACCREDIT THE SYSTEM. 

B. ALL NAVY NETWORKS SHALL BE CERTIFIED AND ACCREDITED BY THE 
RESPECTIVE SITE DAA lAW REF C. 

PER REF A, THE DAA RESPONSIBLE FOR THE OVERALL SECURITY OF THE 
NETWORK SHALL HAVE THE AUTHORITY AND 
RESPONSIBILITY TO REMOVE FROM THE NETWORK ANY AIS NOT 
ADHERING TO THE SECURITY REQUIREMENTS OF THE NETWORK. 

(I) CERTIFICATION AND ACCREDITATION RESOURCES. 

(A) THE NAVY INFOSEC WEB SITE 

(HTTP:(SLANT)(SLANT)INFOSEC.NAVY.MIL(SLANT)) POSTS 
COPIES OF REFS A THRU F AS WELL AS ADDITIONAL GUIDANCE AND 
TEMPLATES ASSOCIATED 

WITH THE CERTIFICATION AND ACCREDITATION OF SYSTEMS AND 
NETWORKS. THIS INFORMATION 

CAN BE FOUND IN THE INFOSEC SERVICES PORTION OF THE WEB PAGE 10 
RUENAAA4545 UNCLAS SITE. 

(B) DISA'S INFORMATION ASSURANCE SUPPORT ENVIRONMENT (lASE) WEB 
SITE (HTTP:(SLANT)(SLANT)MATTCHE.IIIE.DISA.MIL(SLANT)) 

POSTS COPIES OF REFS A AND B AND ADDITIONAL GUIDANCE, 

TEMPLATES, AND TOOLS ASSOCIATED WITH THE CERTIFICATION AND 
ACCREDITATION OF SYSTEMS. 

(C) ALL PROGRAM MANAGERS AND RESPECTIVE RESOURCE SPONSORS 
ARE RESPONSIBLE FOR PLANNING, 

PROGRAMMING AND BUDGETING FOR CERTIFICATION, ACCREDITATION 
AND ASSOCIATED SECURITY 
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MEASURES FOR THE AIS THROUGHOUT THE ENTIRE LIFECYCLE OF THE 
SYSTEM AS DELINEATED IN 
THE DITSCAP (REF B). 

(D) THE NAVY CERTIFICATION AUTHORITY, SPAWAR PMW-I6I, SHALL 
PROVIDE GENERAL PROCEDURAL 

AND TECHNICAL ASSISTANCE TO PROGRAMS AND COMMANDS 
THROUGHOUT THE CERTIFICATION AND 

ACCREDITATION PROCESS. PMW-16I IS CURRENTLY RESOURCED TO 
PROVIDE C&A OVERSIGHT AS 

THE NAVY'S CERTIFICATION AUTHORITY. IF REQUIRED, PMW-I6I CAN 
PROVIDE A LIST OF THIRD 

PARTY ORGANIZATIONS WHICH CAN SUPPORT PROGRAMS AND 
COMMANDS WHO DO NOT INHERENTLY 

POSSESS THE TECHNICAL AND/OR PROCEDURAL EXPERTISE TO COMPLETE 
THE ACCREDITATION PROCESS 

(FUNDING FOR SUCH SUPPORT SHALL BE THE RESPONSIBILITY OF THE 
PROGRAM AS DELINEATED 
IN SUB-PARA3.C. ABOVE). 

AS PART OF A LARGER INFOSEC/IA AWARENESS -ROAD SHOW- FOR 
BT 

UNCLAS //N05239// 

FINAL SECTION OF 02PROGRAM MANAGERS, PMW-I6I HAS PREPARED A 
PRESENTATION TO PROVIDE INFORMATION AND AWARENESS ON 
THE DITSCAP BASED CERTIFICATION AND ACCREDITATION PROCESS. 
COMMANDS DESIRING MORE INFORMATION ON THIS PRESENTATION, 
ROAD SHOW, OR WITH GENERAL CERTIFICATION AND ACCREDITATION 
QUESTIONS SHOULD CONTACT PMW-I6I DIRECTLY. 

4. ACTION. REQUEST ADDLES READDRESS/FORWARD THIS MESSAGE, AS 
APPROPRIATE, TO COMMANDS/PROGRAMS WITHIN THEIR 
CLAIMANCY/AREA OF RESPONSIBILITY.// 

BT 

#4545 


133 



THIS PAGE INTENTIONALLY LEFT BLANK 


134 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 
Ft. Belvoir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 

3. Karen Burke 

Department of Information Sciences, Code CS 
Naval Postgraduate School 
Monterey, California 

4. Douglas Brinkley 

Department of Information Sciences, Code IS 
Naval Postgraduate School 
Monterey, California 

5. Dan C. Boger 

Department of Information Sciences, Code IS 
Naval Postgraduate School 
Monterey, California 


135 



